Cubeware Business Intelligence Blog

Wieso kann ich das nicht sehen?

Mrz 5, 14 • AllgemeinNo CommentsRead More »

Das ist aber ein super BI-System! Klasse, wie hier unsere IT mit den Fachabteilungen zusammengearbeitet hat. Besser geht’s nicht!„, freute sich der Geschäftsführer eines deutschen Mittelständlers. „Dann wollen wir mal in medias res: Was muss ich nun machen, um mir die verschiedenen Berichte anzuschauen?

Doch was so selbstverständlich klang, brachte das gesamte Konstrukt zum Einsturz. Was ist passiert?

Eigentlich hatten die IT und die Fachabteilungen doch alles richtig gemacht. Um nicht die Fehler von anderen zu wiederholen, hatten sie sich zusammen an einen Tisch gesetzt und evaluiert, welche Anforderungen eine BI-Lösungen für beide Seiten erfüllen muss. Nachdem sich darauf verständigt wurde, blieben alle Verantwortlichen stets in das Projekt miteinbezogen und konnten rechtzeitig nachschärfen, wenn der Soll- und Ist-Zustand zu weit auseinander zu klaffen drohte. Tauchten Strukturprobleme auf oder galt es, neue Strukturen und Verantwortlichkeiten zu vergeben, versorgten sie sich mit den notwendigen Berechtigungen nach. Das Projekt wuchs und wuchs. Abhängigkeiten wurden immer komplexer und bedingten sich gegenseitig. Am Ende war das BI-System zwar einsetzbereit, doch leider nur für die Projektbeteiligten. Das Hinzufügen neuer Nutzer, und selbst wenn es der Geschäftsführer persönlich ist, bedeutete einen gigantischen manuellen Pflegeaufwand. Flexibles Berechtigungsmanagement? Fehlanzeige!

Sie meinen das sei ein Einzelfall oder gar frei erfunden? Zugegeben, diese Geschichte mutet eher wie eine Parabel an, aber diese oder ähnliche Geschichten tragen sich in vielen IT-Projekten in großen und kleinen Unternehmen auf der ganzen Welt zu.

Und alle würden sich mit einem Blatt Papier, einem Stift und etwas Zeit verhindern lassen.

Berechtigungskonzept

Jede Software-Einführung sollte mit der Erstellung eines Berechtigungskonzepts starten: Welche Interaktionsmöglichkeiten sollen die verschiedenen Nutzer bekommen? Wie sollen sie durch die Applikation geführt werden? Zugriffe, die benötigt werden, dürfen nicht verhindert werden. Tote Verknüpfungen müssen vermieden werden. Wieso also nicht die Berechtigungen entlang der Unternehmensstruktur entwerfen?

Der Gedanke ist naheliegend. Erscheint die Struktur doch nachvollziehbar und hierarchisch gegliedert zu sein.

1

Sobald es jedoch um den Abgleich konkreter Aufgabenverantwortlichkeiten einzelner Leute geht, wird die klare Struktur schnell unübersichtlich: So sind Mitglieder der IT-Abteilung für die verschiedenen Abteilungen als Administratoren vorgesehen, ein weiterer als Systemadmin. Aus der Controlling-Abteilung soll sich jemand um das Reporting der IT-Projekte kümmern. Der Controller für Vertriebsthemen benötigt auch Zugriffe auf die Sales-Berichte. Außerdem benötigt ein Vertriebler Admin-Rechte im selben Bereich, um Berichte erstellen und Kommentierungen vornehmen zu können. Und last but not least benötigt der Chef selbstverständlich auf alles Zugriff – aufgrund seiner geringen IT-Affinität sicherheitshalber aber nur lesend, nicht, dass am Ende die ganzen schönen Berichte auf einmal weg sind.

Ärgerlich, jetzt ist aus der vormals nachvollziehbaren Struktur schon ein Meer von Ausnahmen und Sonderregelungen geworden. Seien Sie versichert, jede Sonderregelung lässt den Wartungsaufwand steigen und steigen, bis schlussendlich ein nicht mehr wartbares System entstanden ist. Mal ganz davon abgesehen was es bedeutet, wenn ein „Schlüsselspieler“ sich einmal beruflich verändern möchte …

Das muss doch auch anders gehen!

2

Warum nicht Rollen?

Anstatt mit Abteilungen und Gruppen zu arbeiten, sollten besser Anwendungsfälle und dazu benötigte Rollen definiert werden. Rollen sind nicht auf Fachabteilungen, sondern auf Anwendungsfälle ausgerichtet. Rollen sollten verschiedene Benutzergruppen anhand ihrer Anforderungen an die Software zusammenfassen und nicht anhand veränderungsanfälliger organisatorischer Einheiten. Alternativ müssten für unterschiedliche Gruppen mit den gleichen Anforderungen die Berechtigungen identisch vergeben werden.

In der Regel lassen sich Rollen für Administratoren, Power-User und Konsumenten definieren. Diesen drei Rollen können mit Leichtigkeit verschiedene Benutzer oder Nutzergruppen aus den einzelnen Abteilungen zugeordnet werden. Gleiches gilt für die Vergabe von Rechten für einzelne Benutzer.

3

 

 

 

 

 

 

 

 

 

 

 

Ein durchdachtes Rollenkonzept lässt sich schnell auf neue Instanzen oder Mandanten eines bestehenden Systems übertragen. So können einfach neue Benutzergruppen zu einem bestehenden System hinzugefügt werden, ohne dass für diese manuell neue Berechtigungen vergeben werden müssen. Es werden Flüchtigkeitsfehler vermieden und der administrative Aufwand sinkt. Sollen beispielsweise die Kollegen aus der Buchhaltung einen Einblick in das Vertriebsberichtswesen bekommen, wird die Benutzergruppe einfach der entsprechenden Rolle hinzugefügt.

Veränderungen kein Problem! Sonderregelungen? Fehlanzeige!

Vorteile?

Durch Rollen- und Berechtigungsmanagement können sich unterschiedliche Bereiche eine Infrastruktur teilen, wodurch die Wartungskosten für die Infrastruktur sinken. Gemeinsam genutzte Berichte müssen nicht redundant vorgehalten werden und Mitarbeiter in Schnittstellen-Funktion müssen nicht ständig zwischen Applikationen wechseln.

Ebenso kann bei einer Software mit hohem Funktionsumfang eine gezielte Reduzierung der Komplexität erreicht werden. Es werden nur die Funktionen angezeigt, die der Benutzer benötigt. Wird etwa nur ein Export als PDF-Dokument benötigt, warum den Nutzer mit zusätzlichen, aber für ihn unnötigen, Optionen wie Excel oder CSV belasten? Für Einsteiger sinkt die Hemmschwelle, da endgültige Fehler, wie das Löschen von Berichten oder Daten, schlicht nicht möglich sind. Es entsteht eine einfach verständliche, einsteigerfreundliche und doch mächtige Applikation, die sowohl Power-User als auch einfache Konsumenten bedient.

Nicht umsonst zählt ein Blatt Papier und ein Stift nach wie vor zu den beliebtesten Arbeitsutensilien.

 

Autor: Christoph Hein, Produktmarketing

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *