Executive KPI Cockpit

Dynamics 365 Finance & Operations does not lack numbers. It lacks one place where the numbers agree.

The finance team reads Financial reporting. Sales reads a workspace tile. Operations reads an SSRS report someone customised four years ago. Someone in the CEO's office rebuilds a board pack in a spreadsheet each month from three exports, and the margin figure in that pack does not match the one on the sales workspace because the two were never given the same definition. Nobody is wrong; there is simply no shared source of a metric. Meanwhile the leadership questions that matter — is the order book converting, is inventory aging faster than it turns, is the production plan slipping, is DSO drifting — each require opening a different module and knowing where to look.

The usual response is a Power BI project. That helps with presentation and does nothing for definition: the same three interpretations of gross margin get rebuilt in DAX, one layer further from the transactions, with no route back to the source document and no owner for the number. Six months later people are exporting from Power BI into a spreadsheet.

What ECOSIRE builds for you

We build a cross-module KPI cockpit inside F&O as an X++ extension in its own model, using Chain of Command and standard extension points with no overlayering. The point of building it inside the ERP is that every figure keeps a live path back to the transaction that produced it.

A KPI is a defined object, not a formula in a report

The core of the build is a KPI definition table: each metric has an owner, a written definition, a calculation source, a unit, a direction of good, a target and a threshold. Add a metric once and it appears everywhere — the cockpit, the alerts, the exported entity, the Excel refresh. Change the definition and everyone changes with it, with the change recorded. This single decision is what stops the three-versions-of-margin problem returning.

The data it reads

Finance metrics come from GeneralJournalAccountEntry and GeneralJournalEntry against your main accounts and financial dimension sets, plus CustTransOpen and VendTransOpen for receivables and payables aging, DSO and DPO. Sales and pipeline metrics come from SalesTable and SalesLine, including order backlog, confirmed versus requested delivery dates and margin at line level. Inventory metrics come from InventSum, InventTrans and InventTable — on-hand value, turns, days of supply, slow-moving and aging buckets by item group and site. Operations metrics come from ProdTable and production orders, PurchTable and PurchLine for supplier lead time and on-time receipt, and WHSWorkTable where warehouse management is in use. Project-driven organisations can include ProjTable measures. We scope exactly which of these your board actually asks about rather than building all of them.

Computation, not screen-time queries

Heavy aggregates are computed by SysOperation batch jobs on a schedule you set and written to snapshot tables, so opening the cockpit does not run a month of ledger aggregation against your production database at nine on a Monday morning. Volatile figures that must be live are read directly and clearly labelled as such. Every snapshot is dated, which gives trend lines that are real history rather than a recalculation of the past using today's master data.

Targets, trends and alerts

Targets are held per metric, per period, per legal entity and optionally per financial dimension, so a group target can be decomposed to a business unit without a second system. Threshold breaches raise F&O alerts through the standard alert framework and can fire business events for downstream consumption — an email, a Teams post, a Power Automate flow, a webhook into whatever your leadership team already reads. The alert carries the metric, the current value, the target, the direction of travel and the drill-through link.

Drill-through that actually lands somewhere

Every tile drills to a list page, and every list page row drills to the source record: the journal entry, the sales order line, the on-hand entry, the production order. A metric that cannot be interrogated will be disbelieved the first time it surprises someone, and disbelief is how cockpits die.

Delivery surfaces

The primary surface is a dedicated F&O workspace with tiles, charts and list pages, usable on the responsive client from a phone or tablet. Alongside it we publish read-only data entities over OData and a Data Management Framework export project, so the same defined metrics feed the Office Excel add-in, Power BI, or your data lake through Synapse Link if you already run one — with the definition still owned in one place. Where you want a Power BI visual embedded in the workspace, we wire it; we do not make Power BI a prerequisite for seeing your numbers.

Security

Access is enforced with the standard security model: purpose-built roles, duties and privileges, and extensible data security policies where a regional director should see only their legal entities or sites. Executive visibility should not mean everyone sees group payroll.

Who this is for

CEOs and managing directors of mid-size and larger organisations running F&O who currently receive a monthly deck instead of a live view. CFOs who want the finance numbers in the same frame as the operational drivers that explain them. COOs and supply chain directors who need inventory, production and supplier performance beside the revenue they support. Group functions running several legal entities that need both the consolidated figure and the entity that is dragging it.

How delivery works

This is a build-to-order application. There is no finished package to download today.

1. Scoping call. We work through the metrics your leadership actually asks for, their definitions, who owns each, your legal entity and dimension structure, and which modules are live. The output is a metric register — usually the most valuable artifact of the whole engagement. 2. Fixed quote. A written scope and a fixed price, agreed before development starts. 3. Build. Typical lead time is two to four weeks, driven by the number of metrics and modules in scope, not by the size of your database. 4. Install in test. Delivered as a deployable package through your Lifecycle Services project into a Tier-2 or higher sandbox, configured against a copy of your data, then validated with your finance and operations leads against figures they already trust. 5. Production. Promoted through your normal LCS release pipeline in your maintenance window, with the batch schedule agreed in advance. 6. Support. A hypercare window for defects and configuration, plus a handover session so your team can add and retire metrics without calling us.

What it deliberately does not do

It does not invent data. If a metric your board wants is not captured anywhere in F&O today, we will say so at scoping and tell you what would have to be recorded first, rather than deriving a plausible-looking proxy. It does not write to your ledger or master data — it is a read and analysis layer. And it does not replace statutory financial reporting; it sits beside it and reconciles to it.