Custom ERP-CRM cockpits: from reporting to operations

A dashboard presents information; an operational cockpit supports decisions and the work that follows. This matters when teams switch between ERP, CRM and spreadsheets to resolve a case. Before commissioning development, identify which role makes which decision and what information is missing. A long list of charts is not a sufficient project scope.

Starting point and project boundaries

• Start with a decision, such as prioritising overdue orders, rather than a list of desired charts.
• Agree definitions of revenue, open orders and availability with business owners; identical labels can conceal different calculations.
• Separate reporting from an operational workspace where staff assign, approve or change business transactions.

Metrics need shared business definitions. Posting dates, time zones and status models can make two correct systems appear inconsistent. The cockpit should show sources and data freshness. Operational actions need the same permissions and validation as the connected business processes. Management aggregates and individual customer records may require different access levels.

• Define the source timestamp and calculation for each metric.

Missing data is not zero and must not silently alter the result.

• Apply organisation permissions to totals and groupings too; an aggregate can still disclose confidential business information.
• Validate write actions against the authoritative system.

An outdated display must not overwrite an order that has already changed.

One possible use case is handling overdue orders. The cockpit combines sales status, delivery information and outstanding tasks. A responsible person identifies the cause of a delay and starts a defined resolution step. Write actions use protected backend functions. This is an illustrative use case, not an additional customer reference.

Practical acceptance scenarios for the first release

• A source stops providing current values. The cockpit shows the last known state and distinguishes unavailable data from genuinely empty results.
• Two departments view the same metric within different responsibilities. Each sees its permitted records and the appropriate total.
• One operator opens a transaction while another changes its status. The action detects the conflict and offers an updated view.

Useful procurement inputs include example views, metric definitions and data sources. Clarify freshness requirements: not every report needs real-time updates. Acceptance criteria should reflect actual roles and tasks, including incomplete data and temporarily unavailable source systems. Loading speed and usability with realistic volumes are part of business quality.

Start with a specific decision the cockpit should support, such as prioritising an overdue transaction or resolving a failed handover. Agree the meaning of each metric, its data owner and the permitted follow-up actions. Explicitly test stale data and conflicting status messages. A cockpit needs visible data freshness so that a quiet screen is not mistaken for evidence of a healthy process.

A management cockpit needs traceable metrics as well as readable charts. Ask the team to trace one number back to its originating transaction and check how delayed data is handled. Business users should be able to identify the reporting cut-off and recognise when a decision requires further verification. Agree metric ownership before the dashboard is accepted.

A checklist for commissioning the work

• Request a shared metric catalogue containing definitions, sources, refresh behaviour and accountable business teams.
• Test the complete route from an overview to an individual transaction and back, including filters and permissions.
• Compare existing BI capabilities with custom development based on the required actions, not only the desired visual presentation.

For a comparable proposal

• Define concrete decisions and their required metrics for each user role.
• Specify calculations, source systems, refresh intervals and missing-data handling.
• Reconcile dashboard values with known business cases through to the source record.

Custom development is particularly useful when standard reporting does not support the workflow or decisions must trigger specific actions. An existing BI tool may be sufficient for reporting alone. Making this distinction avoids unnecessary development and clarifies the scope that genuinely requires a custom application.

Assess the benefit and control further expansion

• Measure the time from detecting an exception to acting on it and count spreadsheet exports still needed outside the system.
• Check whether the cockpit is used in daily work and identify decisions that continue to happen elsewhere.
• Add metrics once their quality and ownership are clear; additional charts do not replace reliable operational control.

Identify an operational decision and the metrics it needs from ERP and CRM. GSWE clarifies calculations and data provenance before developing the cockpit view.

Commission an ERP CRM cockpit: Admin Dashboard for Data and System Control.