1. Einleitung
Modernes Monitoring ist ein komplexes Thema, das sich weit von der reinen Überprüfung der Erreichbarkeit von Systemen entfernt hat. Eine Vielzahl unterschiedlicher Komponenten mit noch unterschiedlicheren Messgrößen will im Blick gehalten werden. Dazu kommt eine immer stärkere Bewegung weg vom reinen Infrastruktur-Monitoring hin zu einer Überwachung ganzer Services. Dabei ändert sich nicht nur die Relevanz einzelner Größen, sondern auch die Art der Größen an sich. So kann ein Service stark von einer einzelnen Applikation abhängen. Damit hängt die Service-Qualität auch sehr stark von der Nutzbarkeit und Performance der Applikation ab. Auch diese Parameter muss man folglich überwachen.
Neue Technologien wie Cloud, Container und IoT (Internet of Things) kommen hinzu. Die Überwachung dieser Bereiche muss ebenfalls berücksichtigt werden, diese gestaltet sich aus unterschiedlichen Gründen komplex.
Zu den angesprochenen Punkten sollen im Folgenden einige Praxisbeispiele aus dem ComConsult-Projektgeschäft dargestellt werden, die viele dieser Aspekte berücksichtigen. Davon ausgehend werden der Service-Gedanke und dessen Einfluss auf das Monitoring beschrieben. Die zusätzlichen Auswirkungen von Cloud, Containern und IoT werden ebenfalls angesprochen.
2. Beispiele aus der Praxis
Zunächst sollen zwei Beispiele aus dem Projektgeschäft der ComConsult präsentiert werden. Hierfür werden die Besonderheiten analysiert und die Fallen aufgezeigt, die bei klassischen Monitoring-Lösungen in einer modernen IT-Infrastruktur auftreten können.
2.1 Beispiel 1: Der zentrale IT-Provider einer Unternehmensgruppe
Dieser Provider will sein Monitoring verstärkt mit Blick auf Einhaltung der vereinbarten Service-Güte verbessern. Dazu wurden zunächst verschiedene Unternehmensbereiche zu ihren Erfahrungen und Erwartungen im Bereich Monitoring befragt, um den Ist-Zustand festzustellen. Die Teilnehmer bei dieser Ist-Aufnahme sind breit gefächert und so auch deren Sichten auf das Monitoring. Die Kernfragen dabei sind:
- Was ist schon auf geeignete Weise in ein Monitoring eingebunden?
- Was kann der Betreiber einer zentralen Monitoring-Lösung sinnvoll für alle Stakeholder leisten?
- Was muss man aus Service-Management-Sicht überwachen und womit?
- Sollte die bisherige Monitoring-Ausstattung durch etwas ganz Neues ersetzt werden, um allen Anforderungen gerecht zu werden?
Diese Fragen wurden unterschiedlich verstanden und beantwortet, sodass sie genauer hinterfragt werden mussten.
2.2 Beispiel 2: Ein Dienstleister, der mit scharfen Vorgaben von Kunden umgehen muss
Der Dienstleister hat getrennte IT-Bereiche und -Werkzeuge für das Kundengeschäft bzw. für seine interne IT-Ausstattung. Die für das Kundengeschäft genutzte zentrale IT-Ausstattung wird größtenteils vom Dienstleister selbst betrieben und überwacht, um den Anforderungen der Kunden gerecht zu werden. Um dem auch in Zukunft Rechnung zu tragen, wird das Monitoring außerdem kontinuierlich verbessert. Für die interne IT-Ausstattung wurden zwischenzeitlich einige Negativerfahrungen mit dem historisch gewachsenen Monitoring gemacht. Diese interne Umgebung soll daher kritisch überprüft und gleich so angelegt werden, dass neue Trends abgedeckt werden können. Dabei stellt sich auch die Frage, inwiefern die Monitoring-Umgebung für das Kundengeschäft für die interne IT sinnvoll einsetzbar ist.
2.3 Analyse
Wenn auch ein wenig verkürzt dargestellt, gehen beide Beispiele auf konkrete Fälle aus der ComConsult-Beratungspraxis zurück. Die gute Nachricht: In beiden und in ähnlichen Fällen konnte den Kunden weitergeholfen werden. Eine Vorgehensweise zur Verbesserung des Monitoring wurde gemeinsam erarbeitet. Dabei wurde einerseits ein schrittweises Vorgehen definiert, das die gewünschten Verbesserungen herbeiführt. Andererseits wurden sowohl der Arbeitsaufwand als auch die Kosten an die Möglichkeiten des jeweiligen Kunden angepasst. Hätte man die gesamte Monitoring-Landschaft auf einmal umgestellt, wären unter Umständen gute Funktionalitäten partiell durch schlechtere ersetzt worden.
Trotzdem stellt sich die Frage: Was war eigentlich das Problem?
In beiden Beispielen waren keine Anfänger im IT-Betrieb am Werk. Auch war eine Monitoring-Ausstattung vorhanden und das Monitoring-Thema als Aufgabenstellung war nicht neu. Wieso waren im ersten Beispiel die Sichtweisen so unterschiedlich? Wieso wurde im zweiten Beispiel nicht einfach das Monitoring aus dem Kerngeschäft als Blaupause verwendet?
Diese Fragen zeigen die Komplexität des Themas. Um die aktuellen Entwicklungen im Bereich Monitoring beschreiben zu können, wird zunächst die Ausgangssituation dargestellt.
3. Modernes Monitoring – die Ausgangssituation
In den oben genannten Beispielen und auch in vielen anderen Projekten hat sich über die Jahre eine gute und stabile Ausgangsbasis für die Gestaltung von Monitoring-Lösungen entwickelt.
Intelligente zu überwachende Komponenten (Managed Objects) und standardisiertes Monitoring
IT-Lösungen mit Intelligenz zur eigenen Statusüberwachung, wie Netzkomponenten oder zentrale Server-Systeme, machen nach entsprechender Konfiguration Meldung an eine zentrale Monitoring-Lösung. Ergänzt um eine gelegentliche Statusabfrage ergibt dies bei Abweichungen eine aussagefähige und zuverlässige Basis für Überwachung und Alarmierung. Heute können Zustände über Parameter standardisiert erfasst werden, sofern es sich um IP-fähige Geräte handelt. Wichtige Stichworte sind hier SNMP (Simple Network Management) Protocol und MIB (Management Information Base).
Produktangebot für zentrales Monitoring und dessen aufwands-optimierten Betrieb
Heute ist es nicht mehr zeitgemäß, nur die Ansprechbarkeit aller überwachten Lösungen mit einem Monitoring-Tool zu überwachen. Wurde hier ein Problem festgestellt, bedeutete dies früher, dass man verschiedene herstellerspezifischen Tools zur Fehlerbehebung einsetzen musste. Soweit man seine Managed Objects mit SNMP-Parametern beschreiben kann, lässt sich ihr genauer Status heute in einer Monitoring-Lösung erfassen.
Monitoring-Software, die alle relevanten Komponenten auf Basis der etablierten Standards und Protokolle einbinden kann, ist von vielen Herstellern erhältlich. Einige Monitoring-Lösungen bieten mindestens teilautomatisiert Hilfestellung an, um eine IT-Landschaft und deren Änderungen in einem zentralen Monitoring zu erfassen. Einige Lösungen gehen sogar noch weiter und ermöglichen Dinge wie
- automatische Erkennung neuer Objekte,
- Möglichkeiten zur übersichtlichen Darstellung,
- verschieden detaillierte Sichten und
- eine automatische Erstellung solcher Sichten basierend auf der Struktur der IT-Landschaft.
All diese Funktionen erleichtern es, mit dem teils rasanten Wachstum der IT-Umgebungen Schritt zu halten.
Übersichtlichkeit und gute Aussagefähigkeit für die IT-Spezialisten
Viele überwachte Objekte und viele Parameter pro Objekt können zu einer Flut von Informationen führen, sodass die Übersichtlichkeit leidet. Um dem entgegenzuwirken, braucht man verschiedene Möglichkeiten, die Informationen zu ordnen, zum Beispiel Filtern, Gruppieren oder Sortieren. Auch das gehört zum Umfang gängiger Monitoring-Lösungen. Natürlich muss man entscheiden, wieviel Geld für solche Möglichkeiten und wieviel Eigenleistung für Feinanpassungen investiert werden sollen. Ist das geklärt, ist ein erster Rahmen für die Tool-Auswahl abgesteckt.
Das klingt nach einer vernünftigen Arbeitsgrundlage:
- Auswahl eines passenden Tools,
- Objekte einbinden,
- Feinschliff bei Konfiguration und Sichten (siehe Abbildung 1),
- Berücksichtigung von Sicherheitsanforderungen durch Einsatz verschlüsselter Protokolle,
- Einrichtung eines Rollen- und Berechtigungskonzepts
und fertig ist das Monitoring-Design.
Abbildung 1: Typische Grundelemente und Funktionen von Monitoring-Lösungen
So ein einfaches Strickmuster funktioniert leider längst nicht mehr (wenn es jemals zu wirklich guten Ergebnissen geführt hat). Die Anforderungen daran, was man mit Monitoring-Informationen und den zugehörigen Tools je nach Situation leisten soll oder muss, gehen weit über solche Grundfunktionalitäten hinaus.
Man betrachte etwa das zweite der eingangs präsentierten Beispiele: Die Monitoring-Gesamtlösung für das Kerngeschäft eines IT-Dienstleisters, der viele as-a-Service-Angebote (XaaS) für verschiedene Kunden betreibt, muss die Anforderungen der verschiedenen Kunden treffsicher abdecken.
Mandantenfähigkeit
Die Service-Level für verschiedene Kunden müssen in unterschiedlich scharfe Alarmschwellen umgesetzt werden können. Anderenfalls würden für alle Kunden dieselben Bedingungen gelten. Jeder Alarm muss akut behandelt werden, auch wenn er sich dann als weniger dramatisch herausstellt. In so einem Fall wird der Service für alle Kunden entsprechend der höchsten Anforderung bepreist. Wie soll man aber den Abnehmern durchschnittlicher Service-Qualität die resultierenden Preise schmackhaft machen?
Vielfach müssen Kunden eines solchen Dienstleisters plausibel die Kontrolle über Service-Güte und Zustände ihrer IT-Ausstattung behalten, um ihrerseits die Vorgaben zu erfüllen. Eine beschränkte Kundensicht auf den grundlegenden Status seiner XaaS-Lösung ist da eine übliche Forderung.
Dadurch wird die Umgebung aber komplexer und es werden neue Anforderungen an das Design der Monitoring-Lösung gestellt. Die Monitoring-Daten sind nicht mehr nur eine wichtige Arbeitsausstattung in der internen Service-Infrastruktur des Dienstleisters, sondern Teile davon werden auch dem Kunden zugänglich gemacht.
Was dem Betreiber der IT-Lösungen eine wertvolle Hilfe für Überblick und schnelle Diagnose ist, kann in den Händen eines unbefugten Dritten das Vorbereiten eines Sicherheitsangriffs deutlich erleichtern: Die anzugreifende IT-Lösung wird schön übersichtlich dargestellt, wichtige Lösungskomponenten sind als solche erkennbar gemacht und noch mit Statusinformationen ergänzt, aus denen sich einiges für einen möglichst gezielten Angriff lernen lässt.
Als natürliche Folge erwarten die Kunden des IT-Dienstleisters, dass die Sicht von außen auf ihre individuellen Monitoring-Daten gegen unbefugten Zugriff geeignet geschützt ist. Darunter fällt auch ein Schutz vor Zugriff durch einen anderen Kunden. Damit stehen Stichworte im Raum wie
- starke Authentisierung,
- Mandantenfähigkeit und
- individuelle Verschlüsselung.
Je nach Kundenanforderungen hinsichtlich Sicherheitsaspekten muss die Lösung mehr oder weniger aufwändig realisiert werden.
Berücksichtigt man all diese Anforderungen, wird deutlich, dass in Beispiel 2 die Monitoring-Lösung für das Kundengeschäft unter Umständen nicht optimal ist, um auch die interne IT abzudecken.
Fazit
An all diesen Punkten erkennt man, dass der allgemein taugliche Kriterienkatalog zur Auswahl eines Monitoring-Tools oder gar das Tool für jedermann sehr schwierige Zielsetzungen sind.
Insgesamt sieht man schon jetzt ein sehr plastisches Praxisbeispiel für das SEF-Theorem: „Von den drei Zielen Security, Economy und Functionality sind maximal zwei zu haben“ (siehe Netzwerk-Insider Ausgabe Juni 2019). Dabei gibt es noch weit mehr Herausforderungen als die bisher betrachteten!
4. Vom Betriebs- zum Service-Management
4.1 Die Ausgangslage
Bei genauerem Hinsehen wurden bisher Eigenschaften von Monitoring-Lösungen betrachtet, die zunächst dem Betreiber einer überwachten Lösung bzw. IT-Landschaft zugutekommen:
- gute Erfassung von Managed Objects und deren Status
- zeitnahe Erkennung von Statusveränderungen
- Möglichkeiten zur strukturierten Sichtung der Informationen für schnelle und erfolgreiche Reaktion auf ungünstige Veränderungen
All dies ist eigentlich klassisches Monitoring & Alarming nebst Unterstützung eines strukturierten Einstiegs in Diagnosen.
Um Erkennungs- und Reaktionszeiten möglichst kurz zu halten, sind zwei Punkte wesentlich: Einerseits möchte man den Überblick behalten, möglichst schon mit Hinweis auf auffällige Teilbereiche, Komponenten oder Systeme. Andererseits soll durch Navigations- und Filtermöglichkeiten die Ursache eingekreist oder mindestens schrittweise der Kreis der Verdächtigen durch Ausschlüsse reduziert werden können.
Können bei einer Lösung Abhängigkeiten automatisiert erkannt oder manuell modelliert werden, erleichtert dies die Fehleranalyse. Dazu ist es notwendig, dass der Verantwortliche über das entsprechende Wissen verfügt, unter anderem:
- Netzinfrastrukturen und ihre Komponenten
- zentrale Systeme, zum Beispiel physische oder virtuelle Server
- wichtige Basisdienste und die Anwendungen, die von diesen abhängen
Weiter ist eine Aufteilung der Betriebsbereiche häufig der Status Quo. Es reicht aber nicht mehr, dass bei einer sinnvollen Arbeitsteilung zu einer IT-Umgebung jeder im Rahmen seiner Zuständigkeiten die nötigsten Daten an das Monitoring liefert. Das zu liefernde Ergebnis hat sich schrittweise weiterentwickelt und wird sich auch weiterhin verändern.
Diese Aufteilung hat auch Konsequenzen beim Umgang mit Auffälligkeiten, insbesondere der Fallzuweisung im Störungsfall. Hier muss bei allen Beteiligten ein Wandel der Denkweise vollzogen werden, von einer strikten Trennung hin zu gemeinsamen Problemlösungsansätzen. Im Optimalfall wird das durch die entsprechende Einrichtung von Monitoring-Intelligenz unterstützt, um eine Zusammenarbeit zwischen den Bereichen zu optimieren.
Beispiel 1: Das Netzwerk als erster Beschuldigter
Der klassische Reflex, bei Störungen ohne sofort klar ersichtliche Ursache zunächst den Netzbetrieb als Verantwortlichen auszumachen, muss durch eine intelligentere Vorgehensweise abgelöst werden.
Richtig ist, dass in der durchgängig vernetzten IT der Netzbereich immer einen Teilbeitrag zu einer Gesamtlösung leistet.
Falsch ist, dass bei Performance-Problemen oder ähnlichen Abweichungen vom Normalzustand mit größter Wahrscheinlichkeit die Problemursache und –Lösung im Netzbereich liegt.
Es ist aber häufig der Status Quo, dass der Netzwerkbereich bei einer Störung zunächst die eigene Unschuld beweisen muss. Dies verzögert eine weitergehende und zielführende Fehleranalyse!
Wenn die eigenen Tools nun Abhängigkeiten berücksichtigen, können schnell diejenigen Komponenten identifiziert werden, die am stärksten vom Soll abweichen. Der Totalausfall eines Kettenglieds wird beispielsweise bei Performance-Problemen selten die Ursache sein.
Die verschiedenen Betriebsbereiche, die an einem Service beteiligt sind, sollten daher allesamt in einem Mindestumfang in ein Monitoring eingebunden sein. Damit werden Ziele wie proaktives Management und das beschleunigte Finden von Problemursachen durch Root-Cause-Betrachtungen erst möglich.
Beispiel 2: Betrachtung einer Anwendung als reine Software
Der Netzbereich ist routinemäßig in ein zentrales Monitoring eingebunden, zentrale Systeme sind in einem gemeinsamen Monitoring auf Erreichbarkeit und Ressourcenauslastung erfasst. Weitere Details werden mit Systemmanagement-Tools durch die verschiedenen Systembetriebsgruppen individuell erfasst. Statuserfassung von Diensten und Applikationen findet selten statt. Wenn überhaupt, dann meist über zugehörige Systemprozesse und Ressourcennutzung.
Trotz dieser separierten Sichten ist jeder mit seiner Monitoring-Ausstattung zufrieden.
Die Wahrnehmung: Anwendungsbetrieb passiert in der Software und im Berechtigungsmanagement. Wenn zusätzliche Ressourcen benötigt werden, müssen Anträge auf Ressourcenerhöhung gestellt werden. Jede Systembetriebsgruppe (zum Beispiel Virtualisierungsbasis, Windows-Server, Linux-Server, …) für sich kommt mit ihrer eigenen Ausstattung an Monitoring-Informationen und Auswertemöglichkeiten zurecht.
Prinzipiell werden so alle Anforderungen erfüllt – bis die nächste kompliziertere (Service-)Störung auftritt. Bei der beschriebenen isolierten Sicht funktioniert eine Ursachenforschung erst, wenn man über die verschiedenen Betriebsbereiche hinweg miteinander spricht. Das bedeutet aber oft: Eine erste Eskalation hat stattgefunden, da keine Betriebsgruppe einen Fehler finden kann.
Fazit
Es wird nicht nur auf technischer Ebene im Tool eine übergreifende Sicht benötigt, sondern auch ein Umdenken im Betrieb. Gerade durch die engere Verzahnung der verschiedenen Bereiche wird es immer wichtiger, miteinander zu reden. Nur so kann der Nutzen der Monitoring-Ausstattung und –Daten erhöht werden.
4.2 Der Service-Manager – ein neuer Stakeholder
Gerade bei der immer stärkeren Verlagerung von reinem Infrastruktur-Monitoring zu einem Service-orientierten Monitoring stellt der Service-Manager einen weiteren, wichtigen Mitspieler dar. Dieser hat die folgenden Aufgaben:
- Überprüfung der Service Level
Ab einem gewissen Umfang des eigenen IT-Service-Portfolios oder für kritische Arbeitsmittel werden meist erhöhte Service Level benötigt. Hier rechtfertigt es sich schnell, einen Service-Manager als spezialisierte Rolle einzuführen, um diese Service Level regelmäßig zu überprüfen.
- Unterstützung der jeweiligen Verantwortlichen
Der Service-Manager unterstützt die verschiedenen Betriebsverantwortlichen durch Rückmeldungen hinsichtlich der erreichten Service-Qualität.
- Aktualität des Service-Portfolios
Er behält die Übersicht über die Prozesse, die Ziele und die zugrundeliegende Technik.
- Neutrale Betrachtung der Abläufe und Performance
Wenn die Betriebsverantwortlichen das Ineinandergreifen ihrer Leistungen und ihre Performance selbst kritisch beobachten sollen, ist ein Zielkonflikt vorprogrammiert. Auch hier kann ein Service-Manager helfen.
Aus der besonderen Sichtweise eines Service-Managers ergibt sich ein anderer Bedarf an Statusinformationen aus dem Monitoring als bei den Betreibern der verschiedenen technischen Lösungen.
Der Service-Manager benötigt weniger Detail-Informationen aus dem Monitoring. Er benötigt Unterstützung bei der Erkennung von Zusammenhängen. Darüber hinaus spielt die Kontrolle der Services und deren aktuellem Zustand eine größere Rolle. Und: Die Perspektive zur Zielkontrolle ist eine andere.
Ein Service-Manager benötigt zusätzlich einen längeren Auswertezeitraum und damit eine längere Aufbewahrung von Informationen als für Echtzeit-Alarmierung oder akute Diagnose nötig. SLAs umfassen oft Zielwerte, die sich auf einen Zeitraum wie Quartal oder Jahr beziehen.
Um eine bessere Idee über die wirkliche Qualität eines Services zu erhalten, bietet sich außerdem der Blickwinkel des Nutzers an.
4.3 Application Performance Monitoring – die Sicht des Nutzers
Die Nutzersicht, oder die Betrachtung auf Anwendungsebene, ist eine sehr empfehlenswerte Verbesserung zur Zusammenarbeit verschiedener Betriebsbereiche in Problemfällen. Sie stellt die wahrgenommene Service-Qualität dar. Dadurch wird sie jetzt zum Qualitätsmaßstab.
Natürlich muss man das Nutzerempfinden erst einmal in messbaren Größen ausdrücken. Typisch ist z.B. das Antwortzeitverhalten auf Applikationsebene. Es gibt mittlerweile umfassende Möglichkeiten zur Gewinnung von Messwerten mit einem entsprechenden Angebot an Tools zur Auswertung. Eine Einbindung in Monitoring-Lösungen ist möglich. Neben dem Umfang an vorbereiteten Auswertemöglichkeiten unterscheiden sich entsprechende Software-Angebote auch dadurch, in welcher Weise sie solche Messdaten gewinnen.
Auswertung realer Nutzeraktivitäten per Browser-Plugin
Bei diesem Szenario ist der Informationsgehalt für die Nutzersicht zwar maximal, jedoch werden die Nutzer umfassend überwacht. Hiermit verbunden sind betriebliche und rechtliche Herausforderungen. Eine Lösung, die keine geeignete Unterstützung zur Einhaltung von Detailregelungen bietet, kommt nicht in Frage. In Momenten geringer Nutzeraktivität gibt es außerdem nur wenige Messpunkte für das Monitoring. Dadurch fällt es möglicherweise zu spät auf, wenn sich die Eigenschaften der beteiligten Lösungen Ende-zu-Ende schleichend verschlechtern (Nachteil für proaktives Monitoring).
Simulation typischer Nutzeraktivitäten und Auswertung der konkreten Antwortzeit
Diese Herangehensweise kann je nach eingesetztem Tool und Häufigkeit von Änderungen in der Benutzeroberfläche der überwachten Applikation zu einem erheblichen Aufwand führen. Denn in vielen Fällen müssen Spezifika der Benutzeroberfläche berücksichtigt werden. In anderen Fällen können Messungen auf Protokoll-Ebene stattfinden. Man erhält in jedem Fall eine gute Näherung für echte Nutzerinteraktion. Zusätzlich sind die Daten statistisch sehr aussagekräftig, da die Aufnahme der Daten immer in exakt gleicher Art und Weise erfolgt. Probleme, die sich bei dem Ansatz der Auswertung echter Nutzeraktivitäten ergeben, entfallen so weitestgehend.
Zusätzliches Profiling der eigentlichen Applikationen
Diese Art des Monitorings geht weit über die Überprüfung der Antwortzeit hinaus, kann aber Entwicklern helfen, Performance-kritische Funktionen aufzufinden, langsame Code-Pfade zu identifizieren und die Software dauerhaft zu verbessern. Mit den Entwicklern kommt ein bislang nicht erwähnter Stakeholder zur Monitoring-Gestaltung mit ins Boot. Das ist aber sehr nützlich: Die Last der Ermittlung und Entschärfung von Problemursachen liegt nicht mehr nur bei den Betreibern der Monitoring-Lösung.
Einzelheiten zu dieser Art des Monitorings würden den Rahmen des hier vermittelten Überblicks zu Monitoring-Bedarf und –Möglichkeiten sprengen. Sie sind einen eigenen Artikel wert.
Tatsache ist jedoch: Möglichkeiten zum Monitoring aus Applikations- und Nutzersicht stehen zur Verfügung.
Abbildung 2: Erweiterter Monitoring-Begriff – alle relevanten Sichtweisen feststellen und bedienen!
4.4 Folgerungen für das Monitoring
Auch wer noch keinen akuten Druck verspürt, derartige Möglichkeiten für eine Überwachung aus Service-Perspektive einzuführen, kann eventuell bestehende Möglichkeiten nutzen, um erste Erfahrungen zu sammeln. Zum Kennenlernen ist eine Marktführer-Lösung vielleicht nicht geeignet. Aussagefähige Parameter und zugehörige Werte kann man aber auch mit weniger Aufwand ermitteln. Wer akuten Bedarf hat, ein Service-Management mit dem notwendigen Kontrollwerkzeug auszustatten, hat am Markt verschiedene Alternativen zur Verfügung. Auch hier ist eine Auswahl notwendig.
Wer bis hierhin durchgehalten hat, verfügt nun nicht nur über erste Denkanstöße, um die eigene Situation neu zu bewerten. Das Eingangsbeispiel Nummer 1 erklärt sich nun auch leichter: Bei der Selbstanalyse, wo vorhandenes Monitoring gut ist bzw. wo es für bessere Service-Qualität Ansatzpunkte oder gar dringenden Bedarf gäbe, kam zunächst eine Liste mit unterschiedlichsten Sichtweisen und Einschätzungen zustande. Ein wesentlicher Grund dafür sind (nachvollziehbare) unterschiedliche Sichtweisen und Antworten auf die Frage „Was soll Monitoring?“. Außerdem haben, wie oben beschrieben, verschiedene Bereiche unterschiedliche Ansprüche an die per Monitoring-Tool mögliche Unterstützung. (siehe Abbildung 2)
