Metrics from your systems, not from after-hours work
Pulling numbers together from several programmes at month end costs days and produces a picture that is already out of date when it arrives. We collect metrics where they already occur in daily operations and keep them available continuously — for management as much as for the departments.
since 2013
experience with business IT (project experience)
50+
projects delivered (project experience)
6
sector focuses in the mid-market
1
named contact throughout the engagement
Entry point and delivery · net plus VAT
- Clarify the decision first, then define the metric
- Data from your existing systems instead of extra data entry
- Fixed price per reporting stream after the analysis
- Operation, adjustment and a named contact after rollout
The entry point is the process analysis from 1,900 € net: we clarify which decisions your business makes repeatedly, which metrics support them and which systems hold the underlying data. Delivery per reporting stream starts at 4,900 € net as a fixed price set after the analysis. Ongoing support starts at 190 € net per month. All prices net plus VAT; third-party licences and fees are listed separately. The full breakdown is on the pricing overview.
Prices as of September 2026. Ongoing services are booked individually and can be cancelled monthly; there is no minimum term.
Most mid-market businesses are not short of figures. The figures exist, they are simply scattered: order data in the inventory system, hours in time recording, complaints in a mailbox, post-costing in a spreadsheet on a shared drive. Only when somebody asks does the work begin — pull exports, align columns, add up totals, explain the differences. The result is a report that is correct but arrives too late, and that has to be rebuilt from scratch the next time. This page describes how to reverse that sequence: which metrics genuinely carry weight in daily operations, how the data for them comes out of your existing systems, how often it needs refreshing and what the presentation looks like for management and for the departments. And we state openly where metrics reach their limits.
One data basis, two views
Why reporting ends up as month-end work
The most common reason is not missing technology but a missing connection. Every system involved can export data, yet none of them knows how the others see the world. The order number is called something different in the second system, customers exist twice, hours are booked to cost centres that the order software does not know. Anyone building a joint report has to recreate that mapping every single time. That is the part which costs days — and the part that can be solved once instead of being repeated every month.
The second reason is habit. A report has grown over the years, somebody built it once, and nobody has asked since whether the figures in it still match the decisions being made today. In our projects we regularly find reports that are maintained at considerable effort and whose output nobody reads any more (project experience). That is why work on metrics does not start with a tool here, but with a question: which decision is this figure meant to trigger, and who makes it? Metrics without an addressee and without an option to act are effort without return.
The third reason is data quality. As long as cases are recorded twice, or part of the work exists only on paper notes, every report reproduces those gaps. Work on metrics is therefore closely tied to the process analysis and to data integration: only once it is clear which system owns which piece of information can a figure be calculated reliably.
The report is not the problem, its source is
Which metrics actually carry weight
A usable metric meets four conditions: it can be calculated from data you already hold, it is defined identically for everyone involved, it moves when something in the business changes, and it has an addressee who can decide something on the basis of it. Drop one of those conditions and you get a figure that people argue about instead of acting on. In our experience the following six areas cover most of what mid-market businesses genuinely steer by (project experience) — which of them make sense in your case is decided during the analysis.
Lead time per case
The time from enquiry to completion, split into processing and waiting. It shows not only how long something takes but at which station the waiting happens — and that is the point where an improvement actually has an effect.
Utilisation and capacity
Planned against genuinely available capacity per team, machine or vehicle. This metric answers whether another job can still be accepted, before the commitment to the customer is made.
Open cases and their age
How many cases are open, and how old the oldest ones are. A pure headcount says little; only the age distribution shows whether something is being left behind and from when it becomes critical.
Rework and complaints
The share of cases that had to be touched a second time, with reason and originating step. This figure exposes costs that otherwise disappear into normal working hours and never appear in any costing.
Contribution margin by job type
Revenue less directly attributable costs, broken down by job type, customer group or region. It shows which business carries the firm and which merely keeps it busy — often with surprising results.
On-time delivery and response time
The share of promised dates that were met, and the time until the first response to the customer. Both are metrics customers notice directly, and both can be derived from data you already hold.
Where the figures come from
For every metric we define, we clarify before delivery which system it comes from, how it is collected technically and who is responsible for the accuracy of the source data. That mapping is the core of the work; the presentation later is the easier part. In practice the data arrives from four directions, frequently combined within one project.
Inventory and order software
Orders, line items, documents and statuses are already structured. Usually read-only access is enough, retrieving the required fields at fixed intervals without putting load on daily operations.
APIs and databases
Where a system offers an interface, we use it; where only database access is possible, we read from a copy. What that looks like in practice is described on the interfaces page.
File exports and archives
Older programmes only hand out data as files. Those exports can be collected, validated and imported automatically — governed and logged instead of done by hand, see document digitisation.
Time recording and shop-floor data
Working hours, machine run times and confirmations from production provide the link between effort and job. Without that link, contribution margin and utilisation remain estimates.
How fresh do the figures need to be?
Not every metric needs updating by the minute. What matters is how quickly a deviation can be acted upon. A utilisation overview used for scheduling on the same day needs a short cycle; a contribution margin by job type that shapes the range once a quarter is fine with an overnight refresh. We set the cycle separately per metric and display it visibly, so that nobody mistakes a figure for being more current than it is.
- Short cycle for metrics that are acted on the same day
- Overnight refresh for reporting with a longer horizon
- Visible state: every view shows when it was last updated
- An alert when a source fails, instead of quietly showing stale figures
| Metric | Cycle | State |
|---|---|---|
| Utilisation per team | every 15 minutes | today 10:45 |
| Open jobs by age | hourly | today 10:00 |
| On-time delivery per month | overnight | today 03:20 |
| Contribution margin by job type | overnight | today 03:20 |
Presentation for management and for departments
The same data basis serves two very different views: management needs a handful of figures with a trend and an indication of whether a deviation needs explaining. The department needs the working list behind it — which specific cases are affected and what to do next. Force both needs into a single view and you get a page that is too detailed for one side and too coarse for the other. We therefore separate overview from working view consistently and connect them through a jump: from the conspicuous figure straight into the list of cases it is made of.
| Aspect | Management view | Department view |
|---|---|---|
| Scope | A few metrics with trend and comparison period | All cases within your own remit, filterable |
| Refresh | Daily or weekly, depending on the metric | In the working rhythm, so the list matches reality |
| Level of detail | Deviation visible, explanation on demand | Individual case with number, owner and date |
| Purpose | Decisions on capacity, pricing and direction | Working through, prioritising and reporting back |
| Output | Overview on screen, optionally a report by email | Working list inside the system people already use |
What metrics cannot do
Metrics show that something is running differently from what was expected. They do not show why. That distinction matters, because a figure quickly turns into an argument although it is only an indication. A longer lead time may stem from a staffing gap, a changed job mix, a supplier delay or simply from a changed recording practice. If the cause is not established, people optimise the figure instead of the process — and that is the point where work on metrics does harm rather than good. We name these limits from the outset and record them in the process documentation.
- A metric describes the past; it does not replace a judgement about the coming weeks.
- What gets measured gets influenced: people assessed by unit counts report unit counts — not necessarily quality.
- Small case numbers fluctuate heavily. With a handful of cases per week, a percentage says very little.
- A metric is only as good as the recording behind it; gaps in the process become gaps in the figure.
- More metrics do not mean more control. An overloaded overview stops being opened after a short while.
In many projects the most useful report is not the one with the most charts, but the single list that shows each morning what will be left undone today if nobody steps in.
How we work
Collect the decisions
We talk to the people who actually decide: management, scheduling, workshop or team leads, accounting. What we collect is not which figures are wanted, but which recurring decisions come up and which piece of information is missing for them today.
Define the metrics
For each decision we define a metric with an unambiguous calculation rule, time reference, scope and owner. These definitions are agreed in writing, so that later discussions are about the result rather than about the arithmetic.
Examine the data sources
We check whether the required fields exist in the systems and are properly maintained. Where data is missing or recorded inconsistently, we say so openly and propose the smallest change to the process that makes the metric dependable.
Connect and prepare
The sources are connected, the data is brought together and the metrics are calculated. Intermediate steps stay traceable: for every figure, the set of cases it was built from can be displayed.
Presentation and rollout
Overview and working view are walked through with the eventual users and adjusted. The rollout uses real cases, not sample data — details are on the training and rollout page.
Operation and adjustment
After the start we monitor the refresh, report failing sources and adjust metrics when the process changes. Ongoing operation is described on the operations and maintenance page.
We talk to the people who actually decide: management, scheduling, workshop or team leads, accounting. What we collect is not which figures are wanted, but which recurring decisions come up and which piece of information is missing for them today.
For each decision we define a metric with an unambiguous calculation rule, time reference, scope and owner. These definitions are agreed in writing, so that later discussions are about the result rather than about the arithmetic.
We check whether the required fields exist in the systems and are properly maintained. Where data is missing or recorded inconsistently, we say so openly and propose the smallest change to the process that makes the metric dependable.
The sources are connected, the data is brought together and the metrics are calculated. Intermediate steps stay traceable: for every figure, the set of cases it was built from can be displayed.
Overview and working view are walked through with the eventual users and adjusted. The rollout uses real cases, not sample data — details are on the training and rollout page.
After the start we monitor the refresh, report failing sources and adjust metrics when the process changes. Ongoing operation is described on the operations and maintenance page.
What metrics and reporting cost
We quote in two steps, because the effort for delivery can only be assessed properly after the analysis. The analysis has a fixed entry price, delivery has a fixed price per reporting stream that is set before work begins. A reporting stream comprises one connected data source, the metrics calculated from it and the associated presentation. Third-party licences and fees are listed separately, so that the running costs are visible from the start.
Prices for metrics and reporting
All prices net plus VAT. The binding fixed price for delivery is set after the process analysis.
Process analysis
The entry point: clarify decisions, metrics and the state of your data.
- Conversations with the decisive roles in your business
- Definition of the load-bearing metrics with calculation rules
- Review of data sources for completeness and upkeep
- Written report with prioritised measures
- Effort range for every proposed reporting stream
Reporting stream
Connect the data source, calculate the metrics, build the presentation.
- Read-only connection to source systems, without interfering with operations
- Calculation of the agreed metrics including control values
- Overview for management and a working view for the department
- A defined refresh cycle per metric
- Rollout on real cases and written documentation
Ongoing support
Operation, monitoring and adjustment after rollout.
- Monitoring of the refresh and alerts when a source fails
- Fault resolution with a named contact
- Adjustment of metrics when processes change
- Additional sources and reports as required
- Operation and data storage on servers in Germany
All prices net plus VAT. The binding fixed price per reporting stream is set after the process analysis. Third-party licences and fees are shown separately from the fixed price.
Not sure which metric to start with?
Tell us which question in your business keeps going unanswered. We will check whether the data for it already exists and give you an effort range before anything gets built.
Typical starting situations
Illustrative scenarios from typical project experience, anonymised and without client details.