Seit dem 1.1.2015 gelten die GoBD und ersetzen die GDPdU und die GoBS (Detailinformationen finden Sie auf unserer Landingpage oder unserer Informationseite ). In der GoBD ist die Regelung bezüglich der Aufbewahrung von steuerrelevanten Daten festgeschrieben. Im Kern müssen diese 10 Jahre archiviert und jederzeit vorlegbar sein. In diesem Zusammenhang benötigen Sie eine GoBD-konforme Kasse, sofern Ihre nicht konform sein sollte. Es gibt 3 Arten von Kassen:

1. Offene Ladenkasse (vereinnahmtes Geld landet in Geldbörse oder Schublade, ohne technische Unterstützung,...)

2. Elektronische Registrierkasse (elektronische Einzelerfassung der Einnahmen)

3. PC-Kasse (Speicherung sämtlicher Geschäftsvorfälle auf dem Kassensystem)

Unabhängig, ob Sie mit einer offenen Ladenkasse oder Registrierkasse oder PC-Kasse arbeiten, muss folgendes sichergestellt sein:

Schritt 1: Täglicher Kassensturz und Führung eines Zählprotokolls

Schritt 2: Übernahme des ausgezählten Kassenbestands in Kassenbericht

Schritt 3: Führung eines Kassenbuchs

Zudem muss für alle betrieblichen Daten folgendes sichergestellt werden:

• die Aufbewahrung (Archivierung) für 10 Jahre sichergestellt ist.

• die Dateien dabei lesbar und exportierbar aufbewahrt werden.

• die Unveränderbarkeit der Daten durch Festschreibung gesichert sein muss.

• Änderungen klar durch Protokolle sichtbar gemacht werden müssen.

• Die Verfahrensdokumentation der von Ihnen im Betrieb eingesetzten Software vorgelegt werden kann

• die Festschreibung der Buchführungsdaten spätestens mit Abgabe der monatlichen Ust-Voranmeldung durchzuführen ist

• die Festschreibung der Kassenaufzeichnungen täglich erfolgt

Zusammenfassend lässt sich sagen, das das Thema GoBD sich nicht auf die Fürhung von Kassen alleine beschränkt. Verfahrensdokumentation, Archivierung, ... sind ebenso zu klären. Deshalb sollten Sie das Thema ganzheitlich lösen und nicht punktuell aktiv werden.

In Unternehmen kann ein Userprozess komplex abzubilden sein. Ursache hierfür ist das Zusammenspiel vieler Bereiche aus dem Unternehmen und die Vielfalt der Aufgaben.

Wie könnte ein Userprozess zum Beispiel bei einem Austritt eines Mitarbeiters vereinfacht aussehen?

Die Personalabteilung ist in den meisten Fällen der Startpunkt. Dann gibt es verschiedene Aktivitäten im entsprechenden Fachbereich und logischerweise bei der IT. Was wären die Aktivitäten (nur auszugsweise als Beispiel)?

1. Information über den Austrittstermin an die verschiedenen Stellen durch die Personalabteilung. Und erhält am Ende des Prozesses die Information, dass alle Aktivitäten abgeschlossen sind.

2. Die IT hat folgende Aufgaben

Account deaktivieren / löschen

- Account deaktivieren / löschen

- Mailkonto sperren

- Entfernen aus Mailverteilern

- Berechtigungen bei Laufwerken usw. entfernen

- Telefonbuch anpassen

- Arbeitsplatzrechner einziehen

- Mobilgeräte einziehen

- Verträge kündigen / deaktivieren

- Lizenzen berücksichtigen / übertragen

- VPN-Accounts / Zugänge deaktivieren

- …

3. Im Fachbereich müssen die internen Aufgaben abgewickelt werden und die IT die entsprechenden Informationen für Entscheidungen mitteilen.

Um diese Aktivitäten zwischen den einzelnen Beteiligten strukturiert koordinieren zu können, ist der Einsatz eines Servicemanagementtools mit integrierter Workflowfunktion notwendig/sinnvoll?. Und für den Workflow ist das Wissen um die aktuelle CI-Struktur essentiell. Warum, wozu, um was zu tun …?

Wenn eine CMDB mit funktionierendem Changemanagementprozess aktuell gepflegt und befüllt ist, erhält man direkt die dem User zugeordneten Informationen: Zum Beispiel besitzt der User ein Mobile Device mit zugeordnetem Vertrag. Daraufhin kann automatisch im Rückgabeprotokoll des Mitarbeiters dieses Gerät mit gelistet (das scheint weniger erwähnenswert als die Kündigung d. entspr. Vertrags) werden. Ein anderes Beispiel wäre das Entfernen aus Mailverteilern, Pickupgruppen fürs Telefon usw. Solche Arbeiten ließen sich zukünftig über Skripte automatisiert durchführen. Ebenso würde das für das Entfernen von Berechtigungen aus Applikationen gelten. Zum Beispiel wäre durch die CMDB bekannt, für welche internen bzw. externen Applikationen der Mitarbeiter Zugänge besitzt und diese könnten ebenso über Skripte deaktiviert / entfernt werden.

Neben den zugeordneten Geräten gibt es in Bezug auf Daten und Zugriffe etliche Abstimmungen und Entscheidungen, die der jeweilige Fachbereich für die IT treffen muss. Dazu gehört beim Mailpostfach, ob dieses mit dem Austritt gelöscht werden soll oder ob ein anderer Mitarbeiter darauf Zugriff erhalten soll (Klärung Datenschutzfragen!) oder ob die Mailadresse weiterverwendet und auf einen anderen Mitarbeiter weitergeleitet wird (zum Beispiel wurde Adresse in Publikationen verwendet). Oder die Frage nach dem Umgang mit dem persönlichen Laufwerk des Mitarbeiters (oftmals sind dort noch geschäftliche Informationen abgelegt). Diese Fragen lassen sich nicht von der IT beantworten, aber die IT muss dem Fachbereich die vollständigen Informationen über die Datensituation des Mitarbeiters aufbereiten und zur Entscheidung zur Verfügung zu stellen. Oftmals wissen weder die Vorgesetzten des Mitarbeiters noch er selbst, auf welche Daten Sie Zugriff haben.

Das sind bei angewendeten Servicemanagementprozessen (Changemanagement, Service Request Fulfilment, Accessmanagement …) Informationen über einen Mitarbeiter, die sich in der CMDB über definierte Beziehungen zwischen CI-Typen (zum Beispiel: Ein User besitzt einen Arbeitsplatzrechner usw.) darstellen lassen.

Zusammenfassend lässt sich sagen, dass ohne eine funktionierende CMDB kein Servicemanagement möglich ist. Außerdem erfordert die Abbildung von Workflows und die Automatisierung aktuelle Daten aus einer CMDB (umformuliert, getroffen?). Die Beschreibung der Aufgaben und das Zusammenspiel mit dem Beispiel eines Userprozesses wurde vereinfacht dargestellt. Gerade bei diesem Prozess gibt es noch eine Vielzahl weiterer zu berücksichtigender Aspekte. Dieser Artikel sollte Ihnen einen ersten Eindruck einer praxisorientierten Nutzung einer CMDB geben.

Hier könnte ich mich kurz fassen und einfach mit „Ja“ antworten.

Eine der zentralen Forderungen in Servicemanagement-Projekten ist regelmäßig die Einführung / Integration einer CMDB. Dies können wir aus unserer Erfahrung und den Kundenprojekten nur bestätigen und unterstützen. Was bedeutet dies aber in der Umsetzung?

In diesem Teil möchte ich das Thema CMDB allgemein beschreiben. In einem weiteren Teil werde ich dann den Nutzen einer CMDB anhand von Praxisbeispielen beschreiben, um dann im 3. Teil mögliche Umsetzungen mit unserer Lösung Erizone zu skizzieren.

Lassen Sie uns anfangen, einige Definitionen und Erklärungen nach ITIL zu diesem Thema zu betrachten.

Im Rahmen von ITIL wird nicht von „der CMDB“ gesprochen. Es wird eine oder mehrere CMDBs geben. Dies entspricht auch der Praxis. Wenn zum Beispiel Ihre Hardwarekomponenten in einem anderen System als Ihre Softwarelizenzen gepflegt werden, dann werden Sie diese nicht nochmals in einer weiteren CMDB erfassen. Also ist eine praxisorientierte CMDB eine „Art“ Cloud, die die IT-Systeme untereinander verbindet. Die Gesamtheit ergibt die notwendige Informationsmenge für die Servicemangement-Prozesse.

Damit ergibt sich auch die Kernfunktion einer CMDB. Es geht nicht primär darum, in einer Datenbank möglichst viele technische Informationen zu sammeln, sondern zusätzlich zu den technischen Daten auch die zugehörigen Lizenz-, Finanz- und Vertragsdaten über deren kompletten Lebenszyklus: neben den technischen Daten eines PC oder Servers also dessen Software und Netzanbindung, Angaben zum Standort, zu den Benutzern, Vertragsdaten (Lizenzen, Wartung, SLAs …) usw.

Eine CMDB sollte als Instrument für Planungs-, Analyse- und Pflegeprozesse fungieren. Dazu ist es erforderlich, dass eine CMDB den SOLL-Zustand der Configuration Items (alle Service Assets, die verwaltet werden müssen, um einen Service zu liefern) darstellt. Was bedeutet dies? Wenn zum Beispiel durch einen Scan eines PCs festgestellt wird, dass auf diesem Gerät unter anderem eine HR-Software und eine Grafiksoftware installiert ist, dann ist dies der IST-Zustand. Dies ist zwar zum Beispiel für das Lizenzmanagement interessant, um festzustellen, ob ausreichend Lizenzen vorhanden sind, liefert aber keine Information darüber, ob diese Installationen berechtigt sind. Durch einen Abgleich des SOLL-Zustandes aus der CMDB mit dem IST-Zustand können somit unberechtigte Änderungen (Changes) lokalisiert werden.

Was könnte ein Vorgehensmodell auf dem Weg zu einer praxistauglichen CMDB sein?

1. Definition und Identifikation der Configuration Items
Zunächst stellt sich die Frage, welche Objekte für meine Servicemanagementprozesse relevant sind und welche Informationen und Beziehungen abzubilden sind. Zu viele oder nicht notwendige CIs und Attribute verursachen Aufwand, aber keinen zusätzlichen Nutzen. Hier ist der Servicekatalog ein guter Ansatz, um die relevanten Objekte zu lokalisieren.

2. Planung und Strukturierung der CMDB
Eine der Grundlagen für eine erfolgreiche Umsetzung ist eine CMDB, die leicht zu benutzen, zu verwalten und zu pflegen ist. Zu komplexe Strukturen führen hier selten zum Erfolg. Die Verbindung und Kopplung der Inventory-Systeme, Assetmanagement-Datenbanken … mit der CMDB ist hierbei essentiell.

3. Statusüberwachung des Configration Item Lifecycle
Es ergibt nur Sinn, CIs zu erfassen, die in der Folge auch einer Pflege unterliegen. Das ist weniger ein technisches als vielmehr ein organisatorisches Thema. Sonst ist eine CMDB auch nur ein weiteres Datengrab.

4. Verifizierung von SOLL und IST
Wie schon angesprochen ist dies eine der wichtigen Aufgaben des Configuration-Managements. Dadurch erreichen Sie auf Dauer Qualität, indem Sie die Defizite und Fehler der Servicemanagementprozesse lokalisieren.

Zusammenfassend lässt sich sagen, es gibt nicht „die CMDB“ und es gibt auch keine „Out of the box“-Lösung für alle Kunden. Eine CMDB ist aber ein zentrales Thema und ist mitentscheidend für den Erfolg einer Implementierung einer Servicemanagementlösung.