Individuelles ERP-CRM-Cockpit: vom Reporting zur Steuerung

Ein Dashboard zeigt Informationen; ein operatives Cockpit unterstützt Entscheidungen und die anschließende Bearbeitung. Der Unterschied ist relevant, wenn Verantwortliche zwischen ERP, CRM und Tabellen wechseln müssen, um einen Vorgang zu klären. Vor der Beauftragung sollte feststehen, welche Rolle welche Entscheidung trifft und welche Information dafür fehlt. Eine große Zahl von Diagrammen ist noch kein überzeugender Projektumfang.

Ausgangslage und Projektgrenzen

• Beginnen Sie mit einer Entscheidungssituation, etwa Priorisierung überfälliger Aufträge, statt mit einer Wunschliste von Diagrammen.
• Klären Sie Begriffe wie Umsatz, offener Auftrag oder Lieferfähigkeit gemeinsam mit den Fachbereichen; gleiche Beschriftungen können unterschiedliche Berechnungen verdecken.
• Trennen Sie reines Reporting von einem operativen Arbeitsplatz, an dem Mitarbeitende Vorgänge zuweisen, freigeben oder ändern.

Kennzahlen benötigen eine gemeinsame fachliche Definition. Unterschiedliche Buchungszeitpunkte, Zeitzonen und Statusmodelle können dazu führen, dass zwei korrekte Systeme scheinbar widersprüchliche Werte zeigen. Das Cockpit sollte Datenquelle und Aktualität erkennbar machen. Für operative Aktionen gelten dieselben Berechtigungen und Validierungen wie in den angebundenen Fachprozessen. Aggregierte Daten für das Management und einzelne Kundenvorgänge können unterschiedliche Zugriffsebenen erfordern.

Architektur, Risiken und Aufwandstreiber

• Definieren Sie Datenstand und Berechnung je Kennzahl.

Fehlende Daten sind nicht gleich null und dürfen die Auswertung nicht unbemerkt verändern.

• Beachten Sie Organisationsrechte auch bei Summen und Gruppierungen; eine aggregierte Kennzahl kann vertrauliche Geschäftsinformationen offenlegen.
• Schreibaktionen benötigen Prüfung am führenden System.

Eine veraltete Anzeige darf keine bereits geänderte Bestellung überschreiben.

Ein mögliches Szenario ist die Bearbeitung überfälliger Aufträge: Das Cockpit führt Vertriebsstatus, Lieferinformationen und offene Aufgaben zusammen. Eine verantwortliche Person erkennt den Grund einer Verzögerung und startet einen definierten Klärungsschritt. Schreibende Aktionen laufen über abgesicherte Backend-Funktionen. Dieses Beispiel ist ein vorgeschlagener Anwendungsfall und keine zusätzliche Kundenreferenz.

Konkrete Prüffälle für den ersten Release

• Eine Datenquelle liefert keine aktuellen Werte. Das Cockpit zeigt den letzten bekannten Stand und unterscheidet fehlende von tatsächlich leeren Ergebnissen.
• Zwei Abteilungen betrachten dieselbe Kennzahl mit unterschiedlichen Zuständigkeiten. Beide sehen die jeweils erlaubten Datensätze und eine passende Gesamtsumme.
• Ein Bearbeiter öffnet einen Vorgang, während ein anderer dessen Status ändert. Die Aktion erkennt den Konflikt und bietet eine aktuelle Sicht an.

Klären Sie außerdem die benötigte Aktualität: Nicht jeder Bericht braucht Echtzeitdaten. Abnahmekriterien sollten typische Rollen und Aufgaben abbilden, einschließlich unvollständiger Daten und zeitweise nicht erreichbarer Quellsysteme. Auch Ladezeit und Bedienbarkeit bei realistischen Datenmengen gehören zur fachlichen Qualität.

Beginnen Sie mit einer konkreten Entscheidung, die das Cockpit erleichtern soll: beispielsweise einen überfälligen Vorgang priorisieren oder eine fehlerhafte Übergabe bearbeiten. Vereinbaren Sie die Bedeutung jeder Kennzahl, den verantwortlichen Datenlieferanten und die erlaubten Folgeaktionen. Testen Sie veraltete Daten und widersprüchliche Statusmeldungen ausdrücklich. Ein Cockpit braucht eine erkennbare Datenaktualität, damit eine ruhige Oberfläche nicht irrtümlich als Beleg für einen störungsfreien Prozess verstanden wird.

Ein Management-Cockpit braucht nachvollziehbare Kennzahlen statt lediglich ansprechender Diagramme. Lassen Sie eine Zahl bis zum Ursprungsvorgang zurückverfolgen und prüfen Sie den Umgang mit verspäteten Daten. Fachbereiche sollten erkennen können, auf welchem Stand die Anzeige beruht und wann eine Entscheidung zusätzliche Prüfung benötigt.

Entscheidungshilfe für die Beauftragung

• Fordern Sie für jede Kennzahl Definition, Quelle, Aktualisierung und verantwortlichen Fachbereich in einem gemeinsamen Verzeichnis.
• Lassen Sie einen vollständigen Weg von der Übersicht zum einzelnen Vorgang und zurück prüfen, einschließlich Filterzustand und Berechtigungen.
• Vergleichen Sie vorhandene BI-Funktionen mit Individualentwicklung anhand benötigter Aktionen, nicht allein anhand der gewünschten Darstellung.

Für ein vergleichbares Angebot

• Konkrete Entscheidungen und die dafür benötigten Kennzahlen je Nutzerrolle definieren.
• Berechnung, Quellsystem, Aktualisierungsintervall und Umgang mit fehlenden Daten festlegen.
• Dashboardwerte an bekannten Geschäftsvorgängen bis zum Ursprungsdatensatz abgleichen.

Individuelle Entwicklung lohnt sich besonders, wenn Standardreporting die Arbeitsabläufe nicht ausreichend unterstützt oder wenn Entscheidungen mit eigenen Aktionen verbunden werden müssen. Für reine Auswertungen kann ein vorhandenes BI-Werkzeug genügen. Diese Abgrenzung spart unnötige Entwicklung und macht den verbleibenden individuellen Umfang klarer.

Nutzen bewerten und den Ausbau begrenzen

• Messen Sie die Zeit von der erkannten Abweichung bis zur Bearbeitung und die Zahl zusätzlich benötigter Tabellenexporte.
• Prüfen Sie, ob das Cockpit im täglichen Prozess genutzt wird und welche Entscheidungen weiterhin außerhalb der Anwendung stattfinden.
• Erweitern Sie Kennzahlen erst, wenn ihre Datenqualität und Verantwortlichkeit geklärt sind; mehr Diagramme ersetzen keine belastbare Steuerung.

Nennen Sie eine operative Entscheidung und die Kennzahlen, die dafür aus ERP und CRM zusammenkommen müssen. GSWE klärt Berechnung und Herkunft vor der Entwicklung Ihrer Cockpitansicht.

Ein ERP-CRM-Cockpit entwickeln lassen: Admin Dashboard für Daten und Systemsteuerung.