Das Versprechen

„Single Pane of Glass“ ist einer der am häufigsten verwendeten Begriffe in der Unternehmenssoftware. Das Versprechen ist einfach und verlockend: Alle Ihre Daten an einem Ort, für jeden einsehbar. Kein Wechseln mehr zwischen verschiedenen Systemen. Keine Informationssilos mehr. Eine Ansicht, eine Wahrheit, ein Bildschirm.

Das klingt wie die Lösung für jedes Koordinationsproblem. Und für eine begrenzte Anzahl von Anwendungsfällen – Führungs-Dashboards, Echtzeitüberwachung homogener Systeme – funktioniert es auch. Wenn alle Teammitglieder dieselben Kennzahlen mit demselben Detaillierungsgrad einsehen müssen, ist eine einheitliche Ansicht sinnvoll.

Das Problem ist, dass die meisten Organisationen nicht so arbeiten. Schon gar nicht im Außendienst.

Wo die Annahme ins Wanken gerät

Das Konzept der zentralen Übersicht geht davon aus, dass Transparenz grundsätzlich gut ist – dass mehr Informationen für mehr Menschen zu besseren Ergebnissen führen. Das trifft bis zu einem gewissen Grad zu, doch ab einem bestimmten Punkt ist es nicht mehr wahr und wird sogar gefährlich.

Wettbewerbsschutz. Wenn mehrere Auftragnehmer an demselben Infrastrukturprojekt arbeiten, benötigen sie Zugriff auf gemeinsame Basisdaten – Kabelverläufe, Mastenstandorte, Kanalinfrastruktur. Sie benötigen jedoch keinen Einblick in die Arbeit der anderen. Wenn Auftragnehmer A den Fortschritt, die Einsatzplanung der Teams und den Materialverbrauch von Auftragnehmer B einsehen kann, stellt dies einen Verlust an Wettbewerbsinformationen dar und führt nicht zu einer Produktivitätssteigerung. Eine zentrale Übersicht, die allen alles anzeigt, macht eine solche Trennung von vornherein unmöglich.

Rollenbezogene Informationen. Ein Außendienstmitarbeiter, der Kabel verlegt, muss seine Aufträge, den entsprechenden Kartenausschnitt und die Materialien sehen, zu deren Entnahme er berechtigt ist. Er muss keine Berichte zur Qualitätskontrolle, Zahlungsberechnungen oder die anderen Teams zugewiesenen Arbeitsaufträge einsehen können. Ihm alles zu zeigen, hilft ihm nicht dabei, besser zu arbeiten. Es erhöht die kognitive Belastung, sorgt für Verwirrung und steigert das Risiko, dass jemand auf der Grundlage von Informationen handelt, die er eigentlich nicht sehen sollte.

Regulatorische und vertragliche Grenzen. In regulierten Branchen – Versorgungsunternehmen, staatliche Infrastruktur, gesundheitsnahe Bereiche – ist Datentransparenz keine Frage der Präferenz. Sie ist eine gesetzliche Vorschrift. Bestimmte Nutzer dürfen bestimmte Datensätze nicht einsehen. Bestimmte Daten dürfen bestimmte Grenzen nicht überschreiten. Ein System, das auf dem Prinzip basiert, dass jeder alles sehen kann, muss diese Einschränkungen nachträglich einbauen – und genau diese nachträglich hinzugefügten Einschränkungen sind es, die versagen.

Operativer Fokus. Wenn ein Projektmanager einen hundert Kilometer langen Glasfaserausbau betrachtet, benötigt er einen Überblick über den Gesamtfortschritt, den Stand des Zeitplans und die Budgetabweichungen. Wenn ein Bauleiter dasselbe Projekt betrachtet, benötigt er die heutigen Arbeitsaufträge, die Berichte von gestern und die Materialverfügbarkeit für diese Woche. Wenn ein Prüfer das Projekt betrachtet, benötigt er das Transaktionsprotokoll und die Genehmigungskette. Allen dreien dieselbe Ansicht zu bieten, hilft keinem von ihnen. Jeder benötigt einen anderen Ausschnitt derselben Daten, dargestellt mit dem für seine Rolle richtigen Detaillierungsgrad.

Das eigentliche Problem, das mit dem „Single Pane of Glass“-Konzept gelöst werden sollte

Der Reiz einer zentralen Übersicht liegt eigentlich nicht in der Transparenz. Es geht vielmehr um zwei tiefgreifendere Probleme, unter denen Unternehmen tatsächlich leiden.

Datensilos. Wenn Informationen in fünf verschiedenen Systemen gespeichert sind, die nicht miteinander kommunizieren, scheitert die Koordination. Das GIS-Team nutzt ein Tool, das Arbeitsmanagement-Team ein anderes, das Bestandsteam ein drittes und das Finanzteam ein viertes. Niemand hat den vollständigen Überblick, da die Daten auf verschiedene Datenbanken verteilt sind, die keinen gemeinsamen Schlüssel haben. Die zentrale Übersicht verspricht, dieses Problem zu beheben, indem sie alles an einem Ort zusammenführt.

Uneinheitliche Daten. Wenn dieselbe Information – wie viele Meter Kabel am Dienstag verlegt wurden – in drei Systemen vorliegt und jedes eine andere Zahl angibt, weiß niemand, welche davon richtig ist. Die zentrale Übersicht verspricht, dieses Problem zu beheben, indem sie als einzige verlässliche Informationsquelle dient.

Beides sind echte Probleme. Die Lösung für Datensilos lautet jedoch nicht: „Zeige allen alles.“ Die Lösung lautet vielmehr: „Speichere alles in einem System und steuere, wer was sieht.“ Und die Lösung für inkonsistente Daten lautet nicht: „Eine Ansicht für alle.“ Die Lösung lautet vielmehr: „Ein Datensatz, der je nach Fragesteller unterschiedlich abgefragt wird.“

Diese Unterscheidung ist entscheidend, denn sie beeinflusst, was Sie entwickeln. Ein System, das auf dem Prinzip „Jeder sieht alles“ basiert, muss später Einschränkungen hinzufügen – und diese Einschränkungen sind immer unvollständig, immer nur ein nachträglicher Einfall und immer das, was bei der Einführung einer neuen Funktion versagt. Ein System, das auf dem Prinzip „die richtige Ansicht für die richtige Rolle“ basiert, integriert Sichtbarkeitskontrollen bereits in die Grundstruktur und macht sie zur Regel statt zur Ausnahme.

Wie die richtige Sichtweise aussieht

Die Alternative zu einer zentralen Übersicht sind keine Informationssilos. Es sind dieselben Daten, dasselbe System, dieselbe verlässliche Quelle – mit einer rollenbasierten Sichtbarkeit.

Gemeinsame Ebenen, getrennte Arbeitsabläufe. Zwei Auftragnehmer, die am selben Glasfaserausbau arbeiten, sehen dieselbe Basisinfrastruktur – Masten, Leitungsrohre, Kabeltrassen. Jeder sieht jedoch nur seine eigenen Arbeitsaufträge, seine eigenen Teamzuweisungen und seine eigenen Installationsberichte. Die Daten befinden sich in einem einzigen System. Die Ansicht ist unterschiedlich.

Funktionsberechtigungen und Sichtrechte sind voneinander getrennt. Einem Außendienstmitarbeiter kann die Berechtigung zum Bearbeiten von Berichten erteilt werden, ohne dass er die Berichte anderer Mitarbeiter einsehen darf. Die Berechtigung, etwas zu tun, und die Berechtigung, etwas zu sehen, sind voneinander unabhängige Steuerelemente. Das bedeutet, dass Sie einem Mitarbeiter innerhalb einer genau definierten Ansicht volle Bearbeitungsrechte gewähren können – genau das, was der Außendienst tatsächlich benötigt.

Vom Server erzwungene Einschränkungen, kein Ausblenden in der Benutzeroberfläche. Wenn ein Benutzer einen Datensatz nicht sehen soll, existiert dieser aus seiner Sicht gar nicht. Er wird nicht hinter einer deaktivierten Schaltfläche versteckt. Er wird nicht aus einer Listenansicht herausgefiltert. Er ist nicht in der API-Antwort enthalten. Er wird nicht in einen Export einbezogen. Die Daten sind tatsächlich nicht vorhanden – denn die Sichtbarkeitssteuerung wird auf dem Server angewendet, bevor die Daten die Datenbank verlassen, und nicht in der Benutzeroberfläche, nachdem sie dort angekommen sind.

Rollenbasierte Dashboards, die auf demselben Datensatz basieren. Der Projektleiter sieht den Gesamtfortschritt. Der Einsatzleiter sieht die heutigen Aufgaben. Der Prüfer sieht das Transaktionsprotokoll. Alle drei greifen auf dieselben zugrunde liegenden Daten zu. Keiner von ihnen sieht alles. Jeder von ihnen sieht genau das, was er benötigt.

Der Anbietertest

Eine nützliche Übung bei der Bewertung jeder Plattform, die eine zentrale Übersicht verspricht: Fragen Sie sich, was passiert, wenn zwei Benutzer die Daten des jeweils anderen nicht sehen dürfen.

Wenn die Lösung separate Bereitstellungen erfordert – separate Datenbanken, separate Umgebungen –, dann wurde die Plattform für vollständige Transparenz konzipiert und kann keine teilweise Transparenz gewährleisten, ohne dass es zu einer Aufsplitterung in Silos kommt. Sie haben ein Problem gegen ein anderes eingetauscht.

Wenn die Lösung eine Filterung auf UI-Ebene beinhaltet – das Ausblenden von Menüpunkten, das Deaktivieren von Schaltflächen, das Filtern von Listenansichten –, dann sind die Daten nach wie vor vorhanden, sowohl in der API als auch in den Exporten. Die Abgrenzung ist rein kosmetischer Natur. Sie hält einer gelegentlichen Nutzung stand, versagt jedoch bei genauerer Betrachtung.

Wenn die Lösung darin besteht, die Filterung auf Anwendungsebene Endpunkt für Endpunkt durchzuführen, dann ist diese Grenze zwar real, aber fragil. Jede neue Funktion, jeder neue API-Endpunkt und jedes neue Exportformat stellt eine potenzielle Sicherheitslücke dar. Die Grenze ist am Tag der Veröffentlichung korrekt, verschiebt sich jedoch mit dem Wachstum der Codebasis.

Wenn die Antwort darin besteht, dass vom Server erzwungene Einschränkungen auf Feldebene gelten, die bereits vor dem Verlassen der Datenbank angewendet werden, dann ist diese Grenze struktureller Natur. Neue Funktionen übernehmen sie. Exporte berücksichtigen sie. API-Aufrufe berücksichtigen sie. Für nicht autorisierte Benutzer existieren die Daten tatsächlich nicht, ganz gleich, wie sie versuchen, darauf zuzugreifen.

Die Frage ist nicht, ob die Plattform Einschränkungen hat. Jede Plattform hat Einschränkungen. Die Frage ist, wo diese Einschränkungen liegen – und ob sie von Anfang an vorgesehen waren oder nachträglich hinzugefügt wurden.

Unterschiedliche Zahlen, alle richtig

Es gibt eine subtilere Variante des „Single-Pane-of-Glass“-Irrtums, die selbst dann noch fortbesteht, wenn man akzeptiert hat, dass verschiedene Rollen unterschiedliche Daten sehen sollten. Es ist die Annahme, dass es immer nur eine Zahl geben sollte – einen Fortschrittsprozentsatz, einen Status, eine Antwort – und dass jede Abweichung zwischen den verschiedenen Ansichten bedeutet, dass etwas nicht stimmt.

In der Praxis führt die Betrachtung derselben Arbeit auf verschiedenen Aggregationsebenen zu unterschiedlichen Zahlen, und jede einzelne davon ist korrekt.

Ein Arbeitsauftrag könnte abgeschlossen sein. Der Mitarbeiter hat das Material abgeholt, das Kabel verlegt und den Bericht eingereicht. Aus Sicht des Arbeitsauftrags beträgt der Fortschritt hundert Prozent. Dieser Arbeitsauftrag war jedoch einer von vier innerhalb einer Aufgabe, und die Aufgabe ist erst zu vierzig Prozent abgeschlossen, da die anderen drei Arbeitsaufträge noch ausstehen. Die Aufgabe selbst ist eine von zwanzig in einem Projekt, und das Projekt ist zu zwölf Prozent abgeschlossen. Drei verschiedene Fortschrittszahlen für denselben physischen Kabelabschnitt – und keine davon ist falsch.

Das ist kein Rundungsfehler und auch kein Abgleichproblem. Es ist die natürliche Folge davon, dass man dieselbe Realität aus unterschiedlichen Blickwinkeln betrachtet. Dem Einsatzleiter geht es um den Arbeitsauftrag – ist der heutige Auftrag erledigt? Dem Projektkoordinator geht es um die Aufgabe – liegt dieser Abschnitt des Netzplans im Zeitplan? Dem Programmmanager geht es um das Projekt – erreichen wir den vierteljährlichen Meilenstein? Jeder von ihnen benötigt eine Zahl, und die richtige Zahl ist für jeden eine andere.

Der Gedanke hinter dem „Single Pane of Glass“-Ansatz lautet: Wähle eine Kennzahl aus und sorge dafür, dass alle sie verwenden. In der Praxis bedeutet das, dass entweder der Außendienstleiter eine Zahl von zwölf Prozent sieht, die für ihn bedeutungslos ist, oder dass der Programmmanager eine Zahl von hundert Prozent sieht, die ihm nichts über den Gesamtzeitplan verrät. Keine der beiden Sichtweisen ist falsch. Sie jedoch in denselben Rahmen zu zwingen, macht beide nutzlos.

Das gleiche Prinzip gilt auch in horizontaler Hinsicht. Zwei Auftragnehmer, die am selben Projekt arbeiten, sehen unterschiedliche Fortschrittszahlen, da jeder nur seine eigene Arbeit einsehen kann. Auftragnehmer A ist zu siebzig Prozent fertig. Auftragnehmer B ist zu dreißig Prozent fertig. Der Projektinhaber sieht beide Zahlen sowie die Gesamtzahl. Alle drei Ansichten sind korrekt. Alle drei sind notwendig. Keine von ihnen ist die „richtige“ Ansicht, die die anderen ersetzen sollte.

Ein System, das darauf ausgelegt ist, für jede Rolle die richtige Ansicht bereitzustellen, bewältigt dies ganz selbstverständlich. Die Daten sind dieselben. Die Aggregation ist unterschiedlich. Die Sichtbarkeitsgrenzen sind unterschiedlich. Und die Zahlen stimmen nicht überein, nicht weil etwas nicht funktioniert, sondern weil andere Fragen gestellt werden – und genau so sollte es auch sein.

Zusammenfassung

Das Konzept des „Single Pane of Glass“ geht davon aus, dass Transparenz grundsätzlich gut ist – dass es zu besseren Ergebnissen führt, wenn allen alles angezeigt wird. Im operativen Einsatz scheitert diese Annahme jedoch an Wettbewerbsgrenzen, rollenspezifischen Informationen, regulatorischen Anforderungen und operativen Schwerpunkten.
Die eigentlichen Probleme, die „Single Pane of Glass“ zu lösen versucht, sind Datensilos und inkonsistente Daten. Beides ist ein echtes Problem. Die Lösung ist jedoch ein System mit kontrollierter Transparenz, nicht eine Ansicht ohne jegliche Kontrollen.
Ein System, das auf dem Prinzip „Jeder sieht alles“ basiert, muss nachträglich Einschränkungen hinzufügen. Ein System, das auf dem Prinzip „die richtige Ansicht für die richtige Rolle“ basiert, macht Transparenzkontrollen zur Grundlage.
Die Alternative zu einem „Single Pane of Glass“ sind keine Informationssilos. Es ist derselbe Datensatz, dieselbe Quelle der Wahrheit, mit rollenabhängiger Sichtbarkeit – gemeinsame Ebenen, wo Zusammenarbeit wichtig ist, getrennte Ansichten, wo Grenzen wichtig sind.
Server-gesteuerte Sichtbarkeitskontrollen, die angewendet werden, bevor Daten die Datenbank verlassen, sind die einzigen Grenzen, die über jeden Zugriffspfad hinweg Bestand haben – UI, API, Exporte und direkte Abfragen. Alles andere ist nur Kosmetik.
Dieselbe Arbeit, betrachtet auf verschiedenen Ebenen – Arbeitsauftrag, Aufgabe, Projekt – ergibt unterschiedliche Fortschrittszahlen, und jede davon ist korrekt. Alle Rollen auf eine einzige Zahl zu zwingen, macht jede Ansicht nutzlos. Unterschiedliche Fragen verdienen unterschiedliche Antworten aus denselben Daten.
Bei der Bewertung einer Plattform geht es nicht darum, ob sie Einschränkungen hat. Die Frage ist, ob die Einschränkungen von Grund auf integriert oder nachträglich hinzugefügt wurden.