Management analytics and reporting

An indicator is a single figure that describes the state of one thing in the company: the margin on an order, a customer's arrears in days past due, the share of deliveries on time. With the board we agree the definition of each indicator: what goes into the margin, from which day a payment counts as overdue, which data make up counterparty risk. To each definition we add the system the figure comes from and the person in the company responsible for it. The result is an indicator glossary, approved by the board before we build the first report.

A dashboard is a screen that shows indicators from the systems' current data, without anyone putting a report together. We build dashboards for the board and heads of department on data from the accounting, sales and industry-specific systems. Every figure on a dashboard leads to the records it came from: from total arrears to the list of invoices, from the margin to the orders. Bringing data from several systems into one place and checking its quality is a separate scope; here we establish how to calculate each indicator from the available data according to the glossary.

An alert is a notification to a designated person when an indicator crosses a threshold agreed with the board: an order's margin has fallen below the set level, or a customer's arrears have exceeded the limit. The notification contains the data that triggered it.

We calculate the risk assessment of a counterparty or transaction from data the company already has: payment history, the size and frequency of orders, disputes and complaints. We agree the assessment rules with the board and write them down. If the data allows, we add a statistical model: a program that calculates the score from how similar transactions ended in the past. The score appears in the system where the decision is made, for example when an order is accepted, with a description of what influenced it. A person makes the decision. An AI agent that takes over a whole stage of a case is a separate scope.

1. We document today's reports. We take the latest board report and the spreadsheets it was built from, and for each figure we record where it comes from and who calculates it. Result: a list of indicators with today's sources, the discrepancies between departments and the manual steps.
2. We agree the definitions with the board. In a workshop each indicator gets one definition, one source and one owner. Result: an indicator glossary approved by the board before the build.
3. We build the dashboards, alerts and risk assessment. We connect the systems, calculate the indicators according to the glossary and compare the result with the last manual report, explaining every difference. Result: dashboards showing the agreed figures and alerts running on the board's thresholds.
4. We hand over responsibility. For an agreed period the manual report and the dashboard run side by side; we teach the person responsible for the glossary to make changes and hand over the instructions. Result: the manual report switched off, and definitions and dashboards run by your people.

1. Where is the definition of each indicator recorded, and who on our side approves it?
2. Where does the dashboard get each figure from, and can every figure be traced back to the records it came from?
3. What will happen to the reports when we change our sales or accounting system?
4. Who receives an alert about a deviation, and how will we know whether silence means no deviations or a stopped data feed?
5. What data is the counterparty risk score based on, and can the person making the decision see what influenced it?
6. Who can change an indicator definition after launch, and is every change recorded with a date and a signature?
7. Does adding a new report require the contractor, or can someone on our side do it by following the instructions?

Which indicators can be calculated from your systems today, and which need changes to the data, is shown by the analysis we start with.