Asset vs CI

In der CMDB werden Configuration Items (CI) verwaltet, Assets werden im Asset Management verwaltet. Aber was ist denn nun ein Asset und was ist ein CI? Wir wollen mit diesem Artikel die Verwirrungen klären.

Asset

Als Asset wird zunächst einmal alles verstanden, was physisch in einem Unternehmen vorhanden ist oder wo ein Preisschild dranhängt (Softwarelizenzen). Das Asset Management beschäftigt sich dabei mit dem Lifecycle des Objektes, also z.B. um vertragliche Dinge, um Kosten, um Inbetriebnahme und um außer Dienst stellen.

Configuration Item

Als CI wird die Konfiguration des Assets bezeichnet, also wie ist die Ausstattung des Assets und welche Zusammenhänge und Abhängigkeiten zu anderen Assets gibt es. Dies wird alles in der CMDB verwaltet.

Alles das Gleiche?

Jetzt kann man auf die Idee kommen, dass es ein und dasselbe ist. Das stimmt leider nicht ganz. Ja, auf der einen Seite ist z.B. ein Laptop ein Asset (er ist physisch vorhanden, hat einen Einkaufspreis und unterliegt einem Lifecycle etc.). Auf der anderen Seite ist der Laptop ein CI, denn es hat eine bestimmte Ausstattung (Software, Speicher etc.) und wird von einem Anwender benutzt.

Beispiel

Noch nicht klar? Machen wir mal ein Beispiel und ich bleibe wieder bei meinem schönen Beispiel des Winzers:

Ein Fass ist ein Asset. Das ist unbestritten. Es hat einen Kaufpreis, evtl. gibt es Garantie darauf und nach einigen Jahres des Gebrauchs wird es ausgemustert. Vollkommen klar.

Das Fass, sagen wir mal ein schönes Barriquefass, kann nun zur Weinherstellung genutzt werden, z.B. für einen herrlich dunkelroten Bordeaux. Ab jetzt ist das Fass ein CI. Es ist in Benutzung und hat einen Zweck zu erfüllen. Das CI ist also ein befülltes Asset. J Durch den Betrieb des Fasses, wird das Asset zum CI.

Nach einigen Jahren wird das Fass nun mit Whisky gefüllt. Das CI ändert sich. Es bekommt einen neuen Zweck. Das Asset ist aber immer noch das Fass. Das Asset selbst ändert sich nicht.

Neue Definition bei neuer Konfiguration

Es kann also sein, dass das Fass in zwei verschiedenen „Systemen“ verwaltet wird, im Asset Management und in der CMDB. Je nachdem was der Winzer nun betrachten möchte, greift er in die CMDB oder in das Asset Management. Will er wissen, wie teuer das Fass war und wie alt es schon ist und ob es mal repariert werden musste, ist das Asset Management die richtige Anlaufstelle. Will er aber nachvollziehen, ob es sich bei dem Wein im Fass um einen 2019 oder 2020 Jahrgang handelt, ist die CMDB the single source of truth.

Doppelte Datenhaltung?

Das klingt immer noch so, als ob das Objekt doppelt verwaltet wird. Nein, zumindest nicht, wenn man ServiceNow als Asset Management und als CMDB nutzt. Hier sind die beiden Objekte (Asset und CI) synchronisiert. Das bedeutet, dass bestimmte Attribute, nennen wir sie mal Stammdaten, im Asset Management und in der CMDB immer identisch sind. Damit einfällt eine doppelte Datenhaltung.

Warum nicht alles in einem?

Ach menno, warum macht man denn nicht alles in einer Tabelle in einem System?

Ganz einfach, weil nicht alle CI’s ins Asset Management fallen und nicht alle Assets automatisch CI’s sind. Stellen Sie sich vor, der schöne Bordeaux wird in einem Fass gelagert, das der Winzer sich von einem befreundeten Winzer geliehen hat. Dann wird dieses spezielle Fass zwar als CI verwaltet, aber das Asset gibt es in der Buchhaltung nicht. Also wird auch kein Asset Management dafür gemacht.

Dann gibt es noch Assets, z.B. einen Gabelstapler, der sehr wohl für die Buchhaltung von Interesse ist, aber keinen direkten Zusammenhang mit dem Wein oder dem Fass hat. Also gehört das ins Asset Management und nicht in die CMDB.

Sollten wir Sie noch Fragen haben, melden Sie sich bei uns. Wenn Ihnen der Artikel gefällt, geben Sie uns ein like und folgen Sie unsere Seite, damit Sie neue Artikel in dieser Art nicht mehr verpassen.

Hinterlassen Sie uns Ihre Kommentare! Lassen Sie uns wissen, wie Sie Ihre Assets und CI’s verwalten. Ich freue mich auf eine rege Diskussion mit Ihnen.

In diesem Sinne: Auf Ihr Wohl.

Nexthink Dashboards

In einem Unternehmen sind Informationen auf allen Ebenen die Basis für strategische und operative Entscheidungen. Egal, ob der Vorstand die zukünftige Ausrichtung des internationalen Konzerns plant, der Bereichsleiter die Umsatzziele festlegt oder der Sachbearbeiter seine tägliche Arbeit plant. Die Ihnen zur Verfügung stehenden Daten bestimmen die Entscheidungen.

In unserer digitalisierten Arbeitswelt werden wir nun mit einer Flut von Daten konfrontiert. Aus dieser Flut gezielt und effizient die relevanten Indikatoren zu finden, die für unsere Aufgaben relevant und entscheidend sind ist oft nicht einfach aber von hoher Bedeutung.

Ein Werkzeug, das uns bei der Bewältigung der Datenflut helfen kann, ist das „Dashboard“.

Was ist ein Dashboard

Der Begriff Dashboard kommt vom englischen Begriff für das Armaturenbrett im Auto. Das Armaturenbrett liefert dem Fahrer alle für den Betrieb des Fahrzeugs notwendigen Informationen in einer bedarfsgerechten, intuitiven Darstellung.

Diese grundlegende Definition lässt sich auch auf andere Gebiete übertragen. „Armaturenbretter“ oder eben Dashboards finden sich deshalb sehr häufig in unserem Umfeld. Sowohl im privaten als auch im beruflichen.

In der IT verwenden es zum Beispiel die Administratoren, um auf einen Blick die wichtigen Parameter der Infrastruktur zu erfassen und Probleme schnell zu erkennen. So lassen sich z.B. auf einem Dashboard rasch die Verfügbarkeit der wichtigsten Web-Applikationen und der Zustand der Microsoft 365 Anbindung erfassen. Ein anderes Dashboard zeigt dem zuständigen Projektleiter den Zustand der Microsoft 365 Einführung und den Adaptionsgrad der neuen browserbasierten Office-Applikationen. Der Abteilungsleiter der Entwicklung bekommt über sein Abteilungs-Dashboard eine Übersicht der genutzten Visual-Studio-Lizenzen gegenüber den angeschafften Lizenzen und den damit verbundenen Kosten.

Dashboarddesign

Ein Dashboard soll dem Anwender Zeit ersparen und ihn in seiner Arbeit unterstützen. Damit das erreicht werden kann, müssen die Dashboards vor allem eines sein: Intuitiv und relevant.

Um das zu erreichen, sollten ein paar „Best Practices“ beim Design von Dashboards beachtet werden:

  • Klären Sie, was der Anwender vom Dashboard erwartet!
    Es ist wichtig, die Zielgruppe genau zu kennen. Sind die Anwender-Personas bekannt, lässt sich die Antwort auf die Frage nach den Erwartungen leichter beantworten.
    Bestimmen Sie die drei bis fünf wichtigsten Informationen, damit alles auf eine Seite passt. Für ein optimales Layout des Dashboards können dann die aus dem Webdesign bekannten Betrachtungsmuster (etwa Z- oder F- Muster) einbezogen werden.
  • Ein gutes Dashboard nutzt Schlüssel-Informationen, um den Anwender zu leiten!
    Dashboards, die das wesentliche mit deutlichen, klaren Zahlen darstellen, vermitteln Vertrauen und Entschlossenheit. Auf diese Weise erkennt der Anwender unmittelbar, was von Relevanz ist.
  • Strukturieren Sie das Informationsangebot!
    Beachten Sie beim Design des Dashboards die Prinzipien der Informationsarchitektur. Mit einer guten Informationsarchitektur kann das Dashboard den Bedürfnissen des Anwenders als auch des Betreibers gerecht werden. Sie hilft das Angebot für die Zielgruppe intuitiv und übersichtlich zu gestalten, berücksichtigt aber auch technische Einschränkungen.
  • Bieten Sie verschiedene Sichten auf die Daten an!
    Erlauben Sie es dem Anwender die Daten zu filtern. Ein Filter auf ein Gebiet oder einen Zeitraum hilft dabei dem Anwender relevante Daten zu präsentieren, ohne das Dashboard unnötig aufzublähen.
  • Verwenden Sie eine konsistente Designsprache!
    Auch wenn trockene Zahlen und Fakten angezeigt werden, kann ein Dashboard optisch ansprechend gestaltet werden. Wichtig ist dabei ein klarer und konsistenter Einsatz von Farben und Schriften, die dem Anwender helfen, sich schnell zurecht zu finden.

Dashboards im Nexthink Portal

Das Nexthink Portal bietet bereits zu vielen Themengebieten Dashboards an, die den genannten „Best Practices“ folgen. Nutzen Sie die Nexthink Library. Für viele Anwendungsfälle finden Sie hier fertige, professionelle Lösungen.

Sollten Sie in der Library nicht fündig werden, da Sie speziellen Anforderungen Ihrer Fachbereiche gerecht werden müssen, stellt das Portal Ihnen aber auch eine Reihe von Werkzeugen zur Verfügung, um diese Anforderungen zu realisieren. Die Einrichtung von Dashboards in Nexthink ist durch die webbasierte Oberfläche sehr einfach und intuitiv zu bewältigen.

Arten von Dashboards

Dashboards werden durch Nexthink in Module gruppiert. Das Modul bestimmt dabei, welche Arten von Dashboards erstellt werden können.

  • Basic Modul
    Dieses Modul erlaubt Metrik-basierte, sehr flexibel anpassbare Dashboards. Sie können verschiedene Metriken auf dem Dashboard darstellen und unterschiedliche Visualisierungen (Widgets) für eine Metrik verwenden.
  • Service Modul
    Das Service Modul erlaubt Dashboards, die auf Services basieren. Jedes Dashboard repräsentiert dabei einen Service. Es ist nicht so flexibel anpassbar wie ein Metrik-basiertes Dashboard. Durch ein vordefiniertes Set an Visualisierungen (Widgets) ist es aber einfacher zu erstellen.
  • Software Metering Module
    Sie benötigen eine Übersicht Ihrer Softwarelizenzen? Dann nutzen Sie das Dashboard in diesem Modul. Die Dashboards bieten Informationen über Installationen, Nutzung und Anzahl von Lizenzen zu den Applikationen an.

Die Werkzeuge

Zur Darstellung der Informationen auf dem Dashboard bietet das Portal eine Reihe von Widgets[1] an.

  • Key Performance Indicator (KPI)
  • Tabelle
  • Liniendiagramm (Line Chart)
  • Balkendiagramm (Bar Chart)

Storytelling mit Daten

Gute Dashboards helfen Zeit und Geld zu sparen. Sie schaffen Transparenz und ermöglichen fundierte Entscheidungen. Gute Dashboards erzählen eine Geschichte und präsentieren trockene Daten und Fakten in einer ansprechenden und aussagefähigen Form.

Fazit

Ein Dashboard innerhalb von Nexthink zu erstellen, ist keine Kunst. Die Kunst, ein erfolgreiches Dashboard-Projekt durchzuführen, liegt in der Planung und Konzeption der Dashboards und der Gestaltung der Informationsarchitektur. Es benötigt Erfahrung, Daten für unterschiedliche Stakeholder aufzubereiten, zu strukturieren und ergonomisch darzustellen.

Sparen Sie sich Geld und Zeit, diese Erfahrung durch „Trial & Error“ zu erlangen. Lassen Sie sich von unseren Experten beraten. Kontaktieren Sie uns!


[1] https://docs.nexthink.com/Experience/2021.4/Types-of-widgets.699466325.html

Sind Sie fit für die Digitalisierung ?

Reifegradanalyse mit der Hochschule Hof

Corona hat die Defizite im Bereich Digitalisierung – wie mit einem Brennglas – deutlich gemacht und den Handlungsdruck deutlich gesteigert. Dies gilt besonders für den öffentlichen Bereich, aber auch für die meisten privatwirtschaftlichen Unternehmen. Soweit so bekannt.

Häufig fehlt aber noch der methodische Ansatz für eine ehrliche und breit angelegte Bestandsaufnahmen im Unternehmen oder der Behörde. Diese wäre aber notwendig, um darauf aufsetzend die richtigen Prioritäten zu setzen und eine konkrete Roadmap zu erarbeiten.

„Ein weiterer wesentlicher Punkt ist“, so Prof. Dr. Heike Markus, „dass die fachliche Auseinandersetzung mit der Digitalisierung vor dem Einsatz der Technologie kommen muss.

Frau Prof. Dr. Heike Markus, Hochschule Hof

Wir haben dazu, gemeinsam mit der Hochschule Hof und ServiceNow ein Reifegradmodell erarbeitet, das eine schnelle und strukturierte Analyse unterstützt. Das Modell berücksichtigt 7 Dimensionen (Strategie, Führung, Prozesse, Technologie, Mitarbeiter, Daten und Steuerung.) und ist aktuell als Online-Umfrage implementiert.

Die Umfrage wird in kürze differenziert für den öffentlichen Bereich und Privatunternehmen zur Verfügung gestellt und die Teilnahme ist für alle Teilnehmer kostenlos. Die Ergebnisse der Umfragen werden anonymisiert ausgewertet und den  Teilnehmern zur Verfügung gestellt.

Interessiert

Weitere Informationen dazu gibt es in unserem Video und in kürze in einem weiteren Beitrag von uns.

Ansprechpartner

Im Impressum der Media Solutions Website findet man die beiden Geschäftsführer Michael Staar und Lukas Fof. Zwei Namen. Michael wollte ursprünglich Rennfahrer werden und Lukas startete seine Karriere bereits als Werkstudent bei uns.

In unseren beiden Interviews haben wir die Menschen beleuchtet, die sich hinter den Namen verstecken und wie sie zu den Köpfen der Media Solutions wurden. Schauen Sie gleich mal rein und erfahren Sie die eine oder andere spannende Neuigkeit!

1. Geschäftsführer/Firmengründer Michael Staar

2. Geschäftsführer Lukas Fof

Das perfekte Projekt

In einem perfekten Projekt wäre alles ganz einfach:

  • Das zu entwickelnde Produkt wäre vollumfänglich bekannt. Sowohl der Kunde als auch der Auftragnehmer wüssten bis ins letzte Detail, wie es am Ende aussehen und was es können sollte.
  • Alle Wünsche und Anforderungen des Kunden wären zwischen diesem und dem Dienstleister(n) abgestimmt, vollständig dokumentiert und von allen am Projekt Beteiligten verstanden.
  • Basierend auf der Dokumentation würde eine nahezu wasserdichte Planung erstellt, die alle Anforderungen sowie Risiken berücksichtigt.
  • Anhand des Plans würde das Produkt entwickelt und natürlich in Time und in Budget fertiggestellt.
  • Und wenn das Produkt dem Kunden am Ende übergeben wird, steht fest: Auch an der Qualität gibt es nichts zu bemängeln. Es entspricht vollkommen dem Erwarteten und liefert den Mehrwert, den sich der Kunde davon erwartet hat, oder es übertrifft ihn sogar.

Die Realität

Wie wir alle wissen und um das ein oder andere Mal erfahren durften, kommt dieses Szenario in Wirklichkeit leider nicht, oder nur höchst selten vor.

Oft existiert zu Beginn eines Projekts nur eine sehr vage Vorstellung von dem Endprodukt.  Einige Anforderungen können vielleicht schon sehr konkret beschrieben werden. Andere, vor allem die komplexeren Themenbereiche sind allerdings für die Beteiligten noch mehr oder weniger eine Black Box. Manche Anforderungen erscheinen essenziell und werden daher mit höchster Priorität sowie unter teilweise großem Aufwand umgesetzt, ergeben sich später dann jedoch als überflüssig oder von nur geringem Mehrwert. Schließlich stellt sich dann noch während der Umsetzung heraus, dass dies und jenes in der ursprünglichen Planung vergessen wurde oder auf andere Art und Weise realisiert werden müsste. In Folge müssen die akribisch erstellten Dokumentationen aktualisiert und der Projektplan überarbeitet werden.

Doch wie kann man mit diesen Unsicherheiten umgehen? Ein agiles Vorgehen (bspw. nach dem Scrum-Framework) und ein damit einhergehendes agiles Anforderungsmanagement kann dabei unterstützen, flexibel und effektiv auf sich ändernde Gegebenheiten zu reagieren. Doch was unterscheidet das klassische Anforderungsmanagement von seinem agilen Pendant?

Klassisches und agiles Anforderungsmanagement – eine Gegenüberstellung

Nachfolgend wollen wir einige Faktoren unter Betrachtung beider Ansätze vergleichen.

 Klassisches AnforderungsmanagementAgiles Anforderungsmanagement
ProduktverständnisEs wird das Ziel verfolgt, das zu entwickelnde Endprodukt bereits zu Beginn vollständig zu erfassen und dessen Entwicklung damit möglichst vorhersehbar und kalkulierbar zu gestalten.Es wird davon ausgegangen, dass sich das Verständnis für das Produkt im Laufe des Projekts entwickeln muss. Hierfür wird auf Erkenntnisse und regelmäßiges Kundenfeedback  im Laufe der Umsetzung gesetzt.
Anforderungs-DokumentationDie Anforderungen werden  in einem Dokument (Lastenheft) vor Beginn der Umsetzung möglichst vollständig und detailliert dokumentiert.Anforderungen werden in Form von Themes, Epics und User Stories erfasst. Sie werden kontinuierlich (auch während der Entwicklung) angepasst und bewertet. Der Detaillierungsgrad von Anforderungen steigt entsprechend ihrer Priorisierung. Noch in weiterer Zukunft liegende Anforderungen werden erst dann näher betrachtet und beschrieben, wenn sie für die Umsetzung in absehbarer Zeit relevant werden.
KommunikationDie Abstimmungen mit dem Kunden erfolgen schwerpunktmäßig zu Beginn des Projekts im Rahmen der Anforderungsaufnahme.Die Abstimmung mit dem Kunden findet kontinuierlich statt. Regelmäßiges Feedback auch während des Entwicklungsprozesses ist ein wesentlicher Bestandteil.
ÄnderungenÄnderungen werden über einen Änderungsantrag initiiert, über den in einem Änderungsgremium (Change-Control Board) entschieden wird. Anschließende werden alle Dokumente und Pläne entsprechend angepasst und die Konfigurations-Baseline auf den neuen Stand gehobenÄnderungen werden durch Anpassung bzw. Erweiterung und Priorisierung des Product-Backlog eingesteuert. Durch die iterative Umsetzung in agilen Projekten kann schneller und flexibler auf sie reagiert werden.
Auslieferung des ProduktsDas Endprodukt wird nach Abschluss der Realisierungsphase an den Kunden übergeben.Eine erste Produktversion steht frühzeitig zur Verfügung und liefert dem Kunden bereits einen Nutzen (MVP – Minimum Viable Product)

Fazit

Klar ist: Das Management von Anforderungen darf nicht mit Beginn der Umsetzung enden. Die wenigsten Projekte kommen ohne Änderungen im Zuge der Umsetzung aus. Sei es, weil sich Anforderungen später als zu unpräzise oder fehlerhaft herausstellen, sich die Wünsche des Kunden ändern, neue Erkenntnisse einen anderen Blick auf das Produkt verschaffen oder Änderungen der Gesetzeslage oder des Marktes Anpassungen erfordern.

Letztendlich kann nicht pauschal das eine oder andere Vorgehen als besser erachtet werden. Beide Ansätze, ob klassisches oder agiles Anforderungsmanagement, haben ihre Berechtigung. In Zeiten komplexer werdender Produkte, sich immer schneller ändernder Rahmenbedingungen sowie neuen Arbeitsstrukturen können agile Vorgehensmodelle ihre Stärken ausspielen. Allerdings ist kein Projekt wie das andere und es muss nicht ausschließlich schwarz oder weiß sein. Aspekte aus beiden Ansätzen lassen sich durchaus sinnvoll miteinander kombinieren. Daher sollte für jedes Projekt beurteilt werden, welcher Mix sich anbietet und wie von den Vorteilen aus beiden „Welten“ profitiert werden kann.