Systems that finally agree, and numbers leadership can use
Several established systems each held part of the truth, and the monthly pack was assembled by hand.
The challenge
- Core systems could not be replaced, and could not talk to each other either.
- The same customer existed three times, with three different identifiers.
- The management pack took days to produce and was out of date on arrival.
- Departments reported different figures for the same period.
Capabilities
- Integration
- Data platform
- Dashboards
- Alerting
What made it complex
Named rather than counted. These are the moving parts the operation already had, and the ones the system had to hold together.
Source systems, kept in place
- Finance
- Operations
- Marketing
Layers built between them
- Incremental, re-runnable pipelines
- Translation and synchronisation
- Matching and merge to one customer identity
- A reporting store where each metric is defined once
What came out
- Leadership dashboards with drill-through
- Team operational boards
- Threshold and anomaly alerts
Control points
- Data quality tests on freshness and completeness
- Row and metric level access control
ConnectsFinance, operations and marketing systems that stayed in place, into one reporting store.
The solution
What we designed and built, part by part.
- 01
Integration layer
A translation and synchronisation layer between the existing systems, so each keeps its own model.
- 02
One customer identity
Matching and merge rules producing a single customer across sources, with conflicts handled and history kept.
- 03
Agreed definitions
A modelled reporting store where each metric is defined once and reused everywhere.
- 04
Dashboards
Live leadership views with drill-through to the underlying records, plus team-level operational boards.
- 05
Alerts
Threshold and anomaly alerts sent to the people who can act, rather than waiting for month-end.
Architecture
The shape of the system, named component by named component. Deliberately abstract: no hostnames, endpoints, credentials or infrastructure layout.
Existing systems, kept
- FinanceConnected
- OperationsConnected
- MarketingConnected
Integration layer
- Incremental, re-runnable pipelines
- Translation and synchronisation
- Matching and merge: one customer identity
Reporting store
- Metrics defined once
- Data quality tests
- Row and metric level access control
Outputs
- Leadership dashboards with drill-through
- Team operational boards
- Threshold and anomaly alerts
Connected: an existing or third-party system we integrated withNothing replaced. A layer built between what was already there.
Technical detail
Described at the level that shows the work without exposing anything belonging to the client.
- Incremental, re-runnable pipelines from each source system
- A semantic layer with single-definition metrics and documented ownership
- Data quality tests on freshness and completeness, alerting on failure
- Row and metric level access control aligned to organisational scope
How it was governed
A delivery standard, not a record of this project. Every engagement is held to these, so nothing below is evidence about this system specifically. The project detail above is.See the method.
Scope agreed before work started
A written scope and a system design, kept current through build and integration. No part of any of these projects began on a verbal scope.
Releases that could be undone
Environments, deployment and a rehearsed way back were part of the build, not added afterwards, so a bad release was recoverable rather than an incident.
Decisions that can be audited
Administrative actions and consequential decisions are logged and reviewable, with roles and row-level rules enforced on the server rather than in the interface.
Integrated without replacement
Where a system was doing its job it was connected rather than rebuilt. Replacement had to earn a business case in every one of these engagements.
Handed over, not held hostage
The data, the integrations and the deployment belong to the client, with export and deletion paths built in advance.
Still our responsibility after launch
Monitoring, support, integration upkeep and a continuing improvement backlog, because launch is a step in the route rather than the end of it.
The outcome
Described qualitatively. Commercial results belong to the client and are shared only with their permission.
- Existing systems keep running while behaving like one platform
- One customer identity across finance, operations and marketing
- The management pack became a live link instead of a monthly project
- Discussion moved from whose number is right to what to do about it
What we owned
The integration layer, identity matching, metric definitions, data quality tests, dashboards and alerting.
Running after launch
Data quality tests on freshness and completeness, plus threshold and anomaly alerts sent to the people who can act.
What this demonstrates
Integration without replacement, identity resolution, governed data and executive reporting.
Related insightWhy your reports disagreeThe identity and definition problems this engagement solved, written up as the pattern behind them.Other projects
Flagship vertical: fitness & wellness · multi-site operator
A single platform for members, payments and access
ReadCustomer services · multi-channel demand
Every enquiry answered on the channel the customer chose
ReadFlagship vertical: fitness & wellness · multi-site operator
Access hardware driven by live business status
Read
Tell us what your business is trying to do.
The first conversation is about your operation, not our services. If we are not the right fit, we will say so.