Konzept über ein Lean BI Framework für KMU

Dieser Artikel ist eine inhaltliche Zusammenfassung meines wissenschaftlichen Artikels "Concept for a Lean BI-Framework for Small and Medium Sized Businesses". Zusätzlich wurde dieser für ein breiteres Publikum aufbereitet, ins deutsche übersetzt und mit weiteren Informationen erweitert. Soweit möglich wurde der Artikel "enttechnisiert" und durch weiterführende Links zum Verständnis ergänzt. Da es sich aber um ein technisches Thema handelt, setzt dieser Artikel ein entsprechendes Basiswissen in Datenbanken und/oder Business Intelligence voraus. Sollten Sie Anmerkungen haben, schreiben Sie mir bitte, ich freue mich auf einen konstruktiven Austausch.

Im Rahmen des Forschungsprojekts an der Fachhochschule Kufstein wurde ein Prototyp entwickelt und in einem Experiment auf Tauglichkeit geprüft. Der ursprüngliche Artikel ist in englischer Sprache verfasst und wurde auf der ERP Future Research Konferenz 2017 in Innsbruck vorgestellt. Der Artikel wird im Tagungsband (Springer Lecture Notes in Business Information Processing: Innovations in Enterprise Information Systems Management and Engineering) in absehbarer Zeit veröffentlich werden.

Die Kernelemente des "Lean BI Frameworks" (LBF) werden in folgender Grafik zusammengefasst:

Bild 1: "Das Lean BI Framework" (Quelle: Eigene Darstellung)

Das LBF nutzt dabei die Prinzipien des "Lean Reportings" und erweitert diese. Das Fundament des LBF bildet dabei eine kosteneffiziente Bereitstellung. Da der BI-Prozess so schlank wie möglich gehalten werden soll, ist es notwendig eine adequate Datenstruktur dazu aufzubauen. Diese soll so generisch und modular (anhand Faktoren wie zum Beispiel der Branche) wie möglich gehalten werden, um den Geschäftsbereichen kurze Entwicklungszeiten zu ermöglichen. Darüber hinaus muss auch eine Agilität vorhanden sein, um notwendige Anpassungen in der Zukunft zu unterstützen.

Ein weiteres Lean-Prinzip ist der "continuous flow" (fortwährender Fluss) und wird durch mehrere Delta Loads am Tag und periodischen Berichten umgesetzt. Diese Berichte sind genau dann verfügbar, wenn diese benötigt werden. Self-service BI gibt dem Anwender die Möglichkeit die Daten mit einem weiteren Lean-Prinzip, dem Pull-Prinzip, zu konsumieren. Weitere Lean-Methoden, welche genutzt werden sind 5S (übersichtliche Berichte und GUIs), Poka Yokes (Fehlervermeidung vor der Abfrage) und PDCA-Zyklus (kontinuierliche Verbesserung). Der BI-Prozess enthält oben genannte Prinzipien, aber da der Fokus auf dem Prozess (und dessen Verbesserung) liegt, wird diesem eine eigene Kategorie gewidmet. 5S und Poka Yoke werden mehr in Berichten verwenden, wohingegen der PDCA eine prozessorientierte Methode darstellt.

Das "Dach des Hauses" bildet der generierte Mehrwert. Dieser kann mit dem allgemein bekannten "magischen Dreieck" aus dem Projektmanagement (Kosten-Zeit-Qualität) gemessen werden. Zusätzlich kann diese Bewertung in verschiedenen Dimensionen je nach Anwendergruppe bewertet werden.

1) Kosteneffiziente Bereitstellung

1.1) Total Cost of Ownership (TCO)

Ein Hauptanliegen eines KMUs ist das Preis-Leistungs-Verhältnis. Daher fokussiert sich das LBF auf eine kosteneffiziente Bereitstellung. Der TCO-Ansatz eignet sich sehr gut, um verschiedene Lösungen und Anbieter miteinander zu vergleichen. Dabei müssen die Kosten des gesamten Lebenszyklus betrachtet werden. Die mathematische Berechnung berücksichtigt also von den Transaktionskosten der Beschaffung, über die Inbetriebnahme und Wartung bis zur Außerdienststellung alle Kosten innerhalb der erwarteten Lebensdauer. Damit die Berechnung nicht zu komplex wird, ist es wichtig, sich auf die relevanten Einflussfaktoren zu konzentrieren. Da die Werte auf Annahmen basieren ist diese Berechnung nicht zu 100% akkurat. Um das Kostenmodel zu beschreiben, ist es notwendig, alle Kostentypen zu beschreiben, welche Einfluss haben. Nur so ist ein transparenter Vergleich möglich. (1) Diese Kosten können nicht allesamt generalisiert werden und müssen daher auf das KMU abgestimmt werden. Nach der Definition der Kostentypen, kann mit der Definition der Kostenfaktoren fortgefahren werden.

Nachdem die Kostenfaktoren ebenfalls definiert wurden, können die Berechnung durchgeführt und die Gesamtkosten ermittelt werden. Es ist nicht möglich eine beste Lösung oder Lieferanten für alle KMUs zu ermitteln, da sich die Rahmenbedingungen erheblich unterscheiden. Daher ist der direkte Vergleich zweier Anbieter und deren Lösungen miteinander keine standardisierte Methode für das LBF. Nichtsdestotrotz ist diese Berechnung eine Voraussetzung für das Konzept und sollte vor eine Implementierung durchgeführt werden.

1.2) On-Premise vs. Cloud

Eine wichtige Entscheidung ist, ob man das Datawarehouse (DWH) in einer lokalen Installation in einem (eigenen) Rechenzentrum (on-premise) oder direkt in der Cloud betreibt. Historisch bedingt war es früher die bessere Wahl für die KMUs sich für eine on-premise-Lösung zu entscheiden. Die Cloud-Lösungen bieten aktuell ein sehr starkes Preis-Leistungs-Verhältnis. Daher ist die Wertschöpfung für Datenbanken sehr groß. Ein relevanter Faktor für die Entscheidung ist die Skalierbarkeit der Datenbank. In Zukunft könnten neue Anforderungen (zum Beispiel: Speichererweiterungen, mehr Speicherkapazität für Analysen, Desaster Recovery, etc.) auftreten. Dies führt dazu, dass diese Kosten den Anschaffungspreis übersteigen und sollten daher auch in der TCO-Berechnung berücksichtigt werden. (2) Accenture hat eine Studie über Cloud-basierende Hadoop-Deployments durchgeführt, welche das bessere Preis-Leistungs-Verhältnis gegenüber on-premise bestätigen. (3) Diese Studie bezieht sich zwar auf Big Data (ist in dieser Version des Frameworks exkludiert), aber diese Aspekte sind ebenfalls auf das LBF anwendbar.

Ein weiterer wichtiger Aspekt sind diverse nicht-funktionale Anforderungen (NFAs), welche ebenfalls besser mit einer Cloud-Lösung abgedeckt werden. Die Teilung zwischen Entwicklungs- und Testumgebung, Qualitätssicherung und Desaster Recovery sind Beispiele für NFAs, welche von den Unternehmen modernisiert werden und daher neue Umgebungen benötigen. Neben den Kostenfaktoren sprechen auch die Elastizität für die Cloud, da Speichergrößen sehr schnell auf die Bedürfnisse der Firma angepasst werden können. (2) Darüber hinaus bietet die Cloud viel bessere Möglichkeiten, um Leistungsverbesserungen durchzuführen. Diese neuen Möglichkeiten sind aber komplexer und zeitaufwändiger verglichen mit den Möglichkeiten von on-premise-Lösungen. (3)

Eine on-premise-Installation bietet der IT-Abteilung eine umfassende Kontrolle über die Daten der Firma und diese kann bestimmen, welche Sicherheitspatches und Softwareupdates installiert werden sollen. Allerdings stellte Infor fest, dass die meisten Sicherheitslücken durch "Inside Jobs" ausgenutzt werden und die Attacken innerhalb der eigenen Firewall der Firma oftmals durch die eigenen Angestellten passieren. Cloud-Server werden dagegen an vielen verschiedenen Stellen gehostet, was sicherer ist, als nur ein Standort. Cloud-Anbieter rollen auch sehr schnell (und automatisiert) Softwareupdates und aktuelle Definitionen für die Virenscanner aus, was diese Tätigkeit ebenfalls ausgelagert. (4)

Sicherheit ist ein sehr wichtiger Aspekt. Das Risiko eines internen Sicherheitsbruchs kann zwar ausgelagert, aber nicht gänzlich eliminiert, werden. Es ist in diesem Falle zwar schwieriger einen konkreten Mitarbeiter zu bestechen, aber dafür hätte hier ein Insider Informationen über viele verschiedene Unternehmen. Cloud-Anbieter bieten zwar eine sichere Umgebung und der Schutz gegen externe Attacken mag besser sein, aber die Kontrolle über die eigenen Daten aufzugeben ist ein nachvollziehbarer schwerer Schritt, den nicht jeder gehen möchte.

Da der TCO für KMUs durch die Cloud geringer ist, stützte sich das LBF auf Cloud-basierende Lösungen in dem Experiment, empfiehlt aber nicht generell eine Cloud-Lösung.

1.3) Proprietäre vs. Open Source BI Suiten

Eine weitere wichtige Entscheidung ist, ob man sich auf lizensierte oder Open-Source Lösungen verlassen möchte. Es gibt einige Open-Source Lizensierungsmodelle, welche kostenlose Lizenzen beinhalten. Das bedeutet aber nicht, dass der TCO dadurch automatisch niedriger ist. Die Kosten der Installation und laufenden Anpassung sind höher, als dies bei den proprietären Suiten der Fall ist. Auf der einen Seite ist der Zugang zu Beratern limitiert und es wird mehr Schulungsaufwand benötigt, aber auf der anderen Seite ist der frei zugängliche und anpassbare Quellcode ansprechend. Das Recht die Software in irgendeiner Weise innerhalb der Firma zu nutzen ohne rechtliche Konsequenzen befürchten zu müssen, macht Open-Source unabhängig. (5)

Kostenpflichtige BI-Technologien verfügen über signifikante Fähigkeiten und Features um viele verschiedene Industrien zu bedienen. Sie sind flexibel und können mit vielen Technologien integriert werden. Da die Produkte kommerziell vertrieben werden, verfügen diese über eine sehr gute Architektur und eine sehr gut getestete Programmversion zum Releasezeitpunkt. Zusätzlich werden Benutzerrechte und Sicherheitsfeatures unterstützt und es gibt umfangreiche Dokumentationen. (5)

Das LBF verlässt sich sich auf proprietäre Lösungen, da diese einen niedrigeren TCO, besseren Support und eine garantierte Zuverlässigkeit bieten. (5)

2) Schlanke Architektur

2.1) Basisarchitektur

Aufgrund der Kostenfaktoren und dem Ausschluss der Nutzung von Big Data wurde ein traditioneller drei-schichtiger Architekturansatz (6) gewählt:

  1. Datenquellen: Bietet Verbindungen zu den Datenquellen
  2. Warehousing: Speichert alle Daten und besteht wiederum aus drei Schichten:
    • Datenintegration: Bereitet die Daten vor
    • Datenmanagement: Speichert die Daten in Data Marts (DM)
    • Datenanalyse: Führt Analysen durch
  3. Präsentation: Bietet Zugang zu den Berichten und Daten für den Benutzer

2.2) Generische Architektur

Das LBF verlässt sich auf eine generische Datenarchitektur, welche die Anforderungen abdecken soll, die alle KMUs haben. Darüber hinaus bietet es eine Flexibilität, um mit den Unterschieden umzugehen. Ein Beispiel: Ein Unternehmen im Bildungsbereich und ein Handelsunternehmen sind völlig unterschiedliche Geschäftsmodelle, beide speichern jedoch Kundendaten. Diese Kundendaten mögen unterschiedlich abgelegt und betrachtet werden, aber im Kern speichern beide Unternehmen personenbezogene Daten wie das Geburtsdatum. Um dies abzudecken, wird der generische Teil in zwei Module geteilt: dem Geschäftsfeld und dem Hersteller der Datenquelle.

Das erste Modul definiert den Geschäftsbereich des KMUs und bietet relevante Strukturen für die Daten. Eine Firma im Bildungssektor benötigt mehr Kundendaten als ein Hersteller von Produkten. Dies beeinflusst die Datenquellen und DWH-Strukturen. Die Daten müssen auch in einer adäquaten Form denormalisiert werden, um die referenzielle Integrität zu gewährleisten. Es ist nicht notwendig, diese Funktionalität auf Daten anzuwenden, die nicht benötigt werden, da dies den Lean-Prinzipien wiedersprechen und "Abfall" generieren würde.

Das zweite Modul leitet sich vom Hersteller des Quellsystems und wird nur auf die Datenquelle angewandt. Ein Beispiel: ein KMU im Bildungsbereich nutzt ein spezielles Buchaltungsprogramm, um die Datenquellen zu exportieren. Das selbe Programm würde die Daten für einen Chemiekonzern in der exakt gleichen Form exportieren. Bei Herstellern, welche anpassbare Exports anbieten, könnte ein generisches Universalformat definiert werden, welches sich direkt am anderen Modultyp orientiert. Das gilt auch für Hersteller, wie zum Beispiel SAP, welche verschiedene Arten von Datenquellen im System anbieten. Realistisch betrachtet ist es nicht möglich für jeden Hersteller am Markt diese Datenquellen zu definieren und die Wartung würde auch sehr viel Zeit benötigen. Daher wurde das Prinzip der Universal Staging Area entwickelt, welches im nächsten Punkt beschrieben wird. Dieses Konzept kann genutzt werden, um die Daten passend zu allokieren, falls das Best-Case-Szenario mit dem Herstellermodul nicht möglich sein sollte.

2.3) Universal Staging Area

Um die generischen Module anzupassen und um neue Felder zu ergänzen, wird eine agile Form der Anpassungsmöglichkeit benötigt. Diese Anforderung führte zum Konzept der Universal Staging Area. Die Staging Tabelle der Universal Staging Area bietet hierbei die Möglichkeit schnell und standardisiert neue Felder in eine Datenquelle zu laden. Die nachgelagerten standardisierten Transformationenversorgen dann den Operational Data Store (ODS). Dieses Konzept ermöglicht es sich bei der Bereitstellung oder Anpassung nur auf den ersten Schritt im ETL-Prozess (Datenladung in die Datenquellen) konzentrieren zu müssen.

Die Staging Area weist die Werte im nachgelagerten Prozessschritt zu und speichert die Werte in separaten Tabellen. All diese Tabellen sind identisch aufgebaut und bestehen aus drei Spalten. Die erste Spalte enthält eine fortlaufende Kennung (ID), welche im Beladungsschritt gemeinsam mit einem Zeitstempel generiert wird. Dieser Zeitstempel wird beim Start des Beladungsprozesses generiert. Dadurch wird gewährleistet, dass alle Daten des Datensets im selben Packet abgelegt werden. Zusätzlich wird ein Identifizierungsmerkmal erstellt, welches den zu beladenen Tabellentyp definiert. Dies ist notwendig um Probleme zu vermeiden, falls zeitgleich mehrere Daten aus mehreren Datenquellen verarbeitet werden. Der Datentyp ist als nummerischer Datentyp definiert. Die zweite Spalte wird genutzt, um die Zeilennummer des Datensets abzulegen und ist ebenfalls von nummerischen Datentyps. Dies wird benötig um den gesamten Tupel im nächsten Schritt aufzubauen. Die dritte Reihe enthält die Daten und ist als Text definiert, damit gewährleistet ist, dass immer sämtliche Daten geladen werden können.

Sollten im Beladungsprozess Probleme auftreten, so können diese später direkt im Warehouse-Layer bearbeitet werden, ohne Daten neu aus dem Quellsystem laden zu müssen. Während der Beladung werden die Daten in die entsprechenden Staging-Tabellen geladen. Jeder Feldwert wird dabei in verschiedenen Staging Tabellen abgelegt und alle Spalten geladen. Danach werden diese Staging-Tabellen genutzt, um die standardisierten Tabellen des ODS zu beladen. Für die korrekte Beladung werden die generierten IDs der Beladungen und die Zeilennummer als zusammengesetzter Primärschlüssel genutzt.

Dieses Konzept der Universal Staging Area gewährleistet, dass eine Standardisierung im zweiten Schritt des ETL-Prozesses möglich ist, da das inhaltliche Mapping bereits im ersten Schritt stattfindet. Falls notwendig können auch mehr als eine Datenquelle (und dadurch mehrere Beladungs-IDs) genutzt werden, um die Daten in das DWH zu bekommen. Dies wird möglich, da die Daten im zweiten Schritt konsolidiert werden und die Beladungs-IDs um Duplikate während der Beladung in die Staging-Tabelle des ODS eliminiert werden. Nachdem alle Daten geladen wurden, werden sämtliche Staging Tabellen wieder geleert.

3) Wertstrom (BI-Prozess)

Das dritte Fundament des LBF stellt ein schlanker BI-Prozess dar.

Dieser Prozess besteht aus fünf Schritten (7):

  • Entwicklung
  • Datenakquise und Datenkonsolidierung
  • Planung
  • Analyse
  • Service

3.1) Entwicklung

Das generische Datenmodell und die aktivierbaren Module sollen die Aufwände in der ersten Bereitstellung senken. Zusätzlich sollen auch zukünftige Bereitstellungen für kommende und zu diesem Zeitpunkt noch unbekannte Anforderungen mit weniger Aufwand durchführbar sein. Das generische Datenmodell bietet hierzu große Vorteile im Bereitstellungsprozess durch die Module, da die entsprechenden Transformationen schon vorhanden sind und nur leichte Änderungen notwendig sind. Die Universal Staging Area stellt hierzu die notwendige Funktionalität bereit, indem sie abhängige Transformationen bereitstellt. Die führt dazu, dass der Hauptaufwand im Datenakquise-Layer bei den Datenquellen liegt. Im weiteren Entwicklungsprozess ist es dann nicht notwendig, den Standardinhalt zu modifizieren. Das LBF kann zusätzliche Ergänzungen in der Zukunft ohne viel Zusatzaufwand mit den Standardmodulen und der Universal Staging Area umsetzen. Aus diesem Grund sollte eine einzigartige Namenskonvention genutzt werden, welche von dem der Standardmodule abweicht, um Redundanzen zu vermeiden. Die Anpassung der Referenztabellen, um andere Texte anzuzeigen, ist möglich, da diese Einträge nicht kritisch sind. Die Möglichkeit dem ODS neue Felder mit Hilfe der Universal Staging Area schnell hinzuzufügen oder diese anzupassen, machen zukünftige Anpassungen möglich.

3.2) Datenakquise und Datenkonsolidierung

Um die Aktualität der Daten zu gewährleisten, werden die Akquise und Konsolidierung in periodischen Intervallen durchgeführt. Große Datenmengen sollten zu einem Zeitpunkt in das System geladen werden, wo dieses nicht durch die Anwender benötigt wird (zum Beispiel in der Nacht). Die Ladung, welche aktuelle Daten enthalten, sollten periodisch mittels importiert und dann im entsprechenden ODS konsolidiert werden. Dazu werden nur neue oder geänderte Daten (Delta-Verfahren) geladen, um unnötiges Datenvolumen zu vermeiden. Die Konsolidierung in den Data Marts muss mit den Anwendern abgestimmt werden, da die Daten während der Laufzeit nicht verfügbar sind. Diese Konsolidierung kann nach der Konsolidierung der ODS stattfinden. Wenn das Beladungsfenster länger dauert, sollte ein eigenes untertägiges Zeitfenster zur Beladung definiert werden (zum Beispiel: in der Mittagspause, wenn die Anwender das System ohnehin nicht nutzen). Diese Maßnahmen gewährleisten, dass die Daten so aktuell wie möglich sind.

3.3) Planung

Im Best-Case-Szenario nutzen die Anwender in den Fachbereichen eine eigene Software zur Planung und Budgetierung. In diesem Falle sollte das DWH die Daten direkt mit dem entsprechendem Standardmodul aus dem Quellsystem laden. Sollte hierzu ein Tabellenkalkulationsprogramm (zum Beispiel Excel) genutzt werden, so sollte ein Speicherplatz auf einem zugänglichen Server definiert werden. An dieser Stelle werden die Daten in einer vordefinierten Struktur im csv-Format abgelegt. Hierzu wird entweder ein Standardmodul oder die Universal Staging Area genutzt. Danach werden die Plandaten in der DWH im nächsten Schritt importiert.

3.4) Analyse

Um den Benutzern das maximale Potenzial aus der BI-Lösung bereitzustellen, ist es notwendig den Benutzern die Möglichkeit zu geben, flexibel und frei mit ihren Daten zu arbeiten. Diese Freiheit wird auch als "Self-Service BI" bezeichnet. Das Data Warehousing Institut (TDWI) stellt in aktuellem Studien fest, dass es in Zukunft für Firmen sehr wichtig sein wird, ihre Organisation um Möglichkeiten zum Self-Service zu erweitern. (8) Hierbei müssen die Benutzer keine eigenen Berichte entwickeln, wenn sie mit den Standardberichten zufrieden sind. Aber aktuelle TDWI-Forschungen zeigen, dass es die Benutzer bevorzugen mit den Daten tiefer zu interagieren und diese produktiver sind, wenn sie die Möglichkeiten bekommen, tiefer in die Daten zu sehen. Darüber hinaus schlägt TDWI vor eine BI- und Analytics-Lösung direkt in das System zu integrieren. (8) Die entspricht dem Konzept eines Management Informations Systems (MIS), in diesem Fall also dem LBF.

3.5) Service

Der ETL-Prozess muss überwacht werden, um auftretende Probleme so schnell als möglich zu beheben. Der ETL-Prozess im LBF baut darauf auf sämtliche Daten ohne Prüfung in die Staging-Tabelle der Datenquelle zu laden und weitere Prüfungen nachgelagert durchzuführen, wenn diese im ODS konsolidiert werden. Dabei werden die Ladeprozesse parallelisiert, um unnötige Wartezeiten beim Import zu vermeiden. Die Ergebnisse der Imports werden protokolliert und bei Problemen wird die IT umgehend und automatisch informiert.

Zusätzlich zu den technischen Checks werden Datenkonsistenzprüfungen durchgeführt. Dabei werden die Summen von Bewegungsdaten über mehrere Data Marts hinweg verglichen und auch Stammdaten-Checks durchgeführt. Eine semantische Prüfung ist mit heute schon durch Nutzung von Big Data und Machine Learning möglich, jedoch erfordert sich entsprechende Ressourcen. Treten in dieser Prüfung Probleme auf, so werden die IT und der Fachbereich automatisch informiert.

Ein weiterer Aspekt ist die Verbreitung der Standardberichte. Wenn sich die Benutzer in das System (zum Beispiel: ein MIS) einloggen, so werden alle vordefinierten Dashboards und Berichte automatisch aktualisiert und statische Berichte entsprechend automatisch verteilt.

4) "Continous Flow" und "Pull"-Prinzipien

Um Wartezeiten auf die aktuellen Zahlen zu vermeiden, nutzt das LBF wie erwähnt das Deltaverfahren, um die Ladezeiten kurz zu halten. Die Zeitfenster, ab wann die Daten zur Verfügung stehen und wann geladen werden kann, muss mit den Benutzern der Fachbereiche abgestimmt werden. Längere Ladungen sollten außerhalb der Geschäftszeiten (zum Beispiel: in der Nacht) durchgeführt werden. Aufwändige Kalkulationen für tägliche Berichte (zum Beispiel gleitende Durchschnittspreise im Bestandscontrolling nach dem First-In-First-Out-Verfahren) sind unter Umständen nur zu diesen Zeiten möglich, weil diese den Geschäftsablauf negativ beeinflussen würden.

Self-Service BI ermöglicht es den Benutzern generell mit den aktuellsten Daten zu arbeiten und diese in beliebiger Dichte zu betrachten, wenn Bedarf danach besteht (Pull). Die vorher definierten Downtimes zur Verarbeitung ermöglichen den Benutzern das Pull-Prinzip anzuwenden, wenn es benötigt wird. (7). Das LBF nutzt Data Marts, welche auch Off-Line funktionieren und diese Downtimes den Workflow der Benutzer nicht negativ beeinflussen (mit Ausnahme bei der Verarbeitung des Data Marts selbst).

5) Laufende Verbesserung (Perfektion)

Perfektion erscheint dem Autor ein irreführender Begriff zu sein, da diese nie erreicht werden kann. Es ist aber ein zentraler Bestandteil des Lean Managements und einige Aspekte dieses Prinzips ermöglichen es dem LBF sich stets zu verbessern. Das LBF nutzt Konzepte der Standardisierung (5S-Methode), Poka Yoke (Fehlervermeidung) und kontinuierliche Verbesserung (PDCA-Zyklus). (7) Im speziellen bei der kontinuierlichen Verbesserung kann es notwendig sein zusätzliche Konzepte des Lean Managements aufzugreifen.

5.1) Standardisierung und Sortierung (angelehnt an 5S)

Passende Kategorien

Alle Berichte und Dachboards können von einem zentralen Punkt aus (zum Beispiel: einem MIS) ausgeführt werden. Die Berichte sind dabei sinnvoll in Kategorien eingeteilt. Erfolgreiche Webseiten orientieren sich an der "3-Klick-Regel", welche besagt, dass der gewünschte Inhalt innerhalb von drei Mausklicks erreichbar sein muss. Sollten die Benutzer länger suchen müssen, verlieren diese das Interesse. (9) Dieses Prinzip wird dabei auf das LBF angewandt, da dies eines der Hauptziele, effiziente Workflows, unterstützt.

Aufräumen und Sortieren

Die vorher definierten Kategorien sollen nur relevante Berichte enthalten und dem Benutzer ermöglichen schnell die Berichte ohne lange Suchzeiten zu erreichen. Diese Einteilung nur bei der Erstellung des Berichts zu machen ist nicht ausreichend. Es muss eine periodische Prüfung durchgeführt werden, ob die Berichte noch benutzt werden (dürfen) oder, ob diese entfernt werden können. Das ist notwendig, da eine große Anzahl an Berichten dem Prinzip des "aufgeräumten" Arbeitsplatzes widerspricht.

Regeldefinition

In jedem Bericht muss ersichtlich sein, welche Information dieser beinhaltet und wie diese Werte zu interpretieren sind und der Bericht gelesen werden kann.

Wiederkehrender Prozess

Der gesamte Prozess muss periodisch wiederholt werden.

5.2) Poka Yoke (Fehlervermeidung)

Wenn ein Bericht mit dynamischen Filterkriterien vor der Ausführung aufgerufen werden kann (zum Beispiel: ein Datumsintervall), müssten Mechanismen implementiert werden, die Falscheingaben vor der Ausführung verhindern. Dies unterbindet falsche Ergebnisse, welche so nicht aus den Daten ableitbar sind. Darüber hinaus können relevante Felder als Pflichteingabe definiert werden, ohne die sich die Abfrage nicht ausführen lässt, bevor diese Kriterien nicht definiert wurden. Es ist schwieriger unlogische Abfragen zu verhindern. Eine Methode wäre es die Kombination von falschen Daten zu verhindern, indem Benutzerrechte zur Anzeige einer Information eingeschränkt werden. Dies unterstützt auch das Konzept von 5S und verringert die Möglichkeiten von falschen Abfragen. Nur fortgeschrittene Anwender (Key User) mit einem entsprechendem fachlichen Hintergrund sollten erweiterte Rechte zum Anzeigen sämtlicher Daten erhalten. (7)

5.3) Kontinuierliche Verbesserung

Um die fachlichen Anforderungen langfristig abzudecken, muss ein PDCA-Zyklus implementiert werden. Dieser PDCA-Zyklus sollte aber nicht nur den "Perfektions"-Teil des LBF abdecken, sondern auf das gesamte LBF angewandt werden.

6) Wert

Das Konzept der LBF schließt damit ab, dass für mehrere Anwendergruppen eine Wertschöpfung stattfinden muss. Dazu werden die vorhin definierten Kategorien nach Bär et al. (7) genutzt. Zusätzlich werden die fünf Benutzergruppen in drei Hauptgruppen eingeteilt:

  1. Benutzer des Fachbereichs (Anwender): Mitglieder in dieser Gruppe sind hauptsächlich an einer effizienten Berichtslösung interessiert.
  2. Technische Benutzer (Administratoren und Entwickler): Diese Gruppe fokussiert sich auf technische Aspekte wie zum Beispiel Laufzeiten der Abfragen und Architekturthemen.
  3. Geschäftsadministration (Management und Sponsor): Diese Gruppe von Stakeholdern definiert sich über Anforderungen des Geschäfts und finanzielle Rahmenbedingungen.

Dem Konzept der kontinuierlichen Verbesserung folgend, werden Umfragen zur Ermittlung der Anwenderzufriedenheit durchgeführt. Diese Umfragen müssen periodisch durchgeführt werden und ein Bestandteil der Lösung (zum Beispiel: im MIS) sein. Faktoren die zu einer Unzufriedenheit führen, müssen so schnell wie möglich bearbeitet werden. Werden nun die drei Faktoren (Kosten, Zeit, Qualität) herabgezogen, so müssen diese für jede Gruppe anders definiert werden, da die Messung aufgrund der unterschiedlichen Zielsetzungen nicht einheitlich sein kann.

Für die Messung der Zufriedenheit der Benutzer des Fachbereichs wird der Zugang zur Messung zur Zufriedenheit der Endbenutzer von Doll et al. herangezogen. Dieser Zugang teilt die kritischen Faktoren in fünf Kategorien ein, um die Gesamtzufriedenheit zu messen: Inhalt, Genauigkeit, Formatierung, Benutzerfreundlichkeit und Aktualität. (10) Die technischen Benutzer fokussieren sich auf funktionale Aspekte. Daher müssen andere Aspekte betrachtet werden. Für Aspekte, welche messbare Daten beinhalten, sollte eine automatisierte Messung der umfragerelevanten Inhalte erfolgen, um Aufwände zu sparen. Die restlichen Inhalte werden nach Dedić et al. gemessen, welche den Zugang von Doll et al. erweitern. Dabei werden folgende Aspekte berücksichtigt: Leistung, Systemanforderungen und Architektur. (11) Die dritte Anspruchsgruppe enthält die Anforderungen der Geschäftsadministration und daher werden Aspekte der Geschäftsanforderungen und finanzielle Aspekte abgefragt. (7)

Schlussbetrachtung

Das besagte Konzept wurde in einem Experiment an der Fachhochschule Kufstein auf Tauglichkeit überprüft. Dieser ganzheitliche Ansatz wurde dabei vom Autor als potenziell wertschöpfend eingestuft. Die im Rahmen der Forschung durchgeführte Umfrage zeigte, dass es jedoch schwierig ist, eine entsprechende Bereitschaft zur Finanzierung durch die KMUs zu generieren. Dies war auch der Grund in der dieser Iteration auf Big Data zu verzichten, da nach dieser Studie derzeit noch der Fokus auf klassischem Berichtswesen liegt und nicht auf Vorhersagenden Modellen. Gartner sagte jedoch schon im Hype Cycle 2015 voraus, dass sich das auf lange Sicht ändern wird. (12) Analysen in der Cloud werden immer attraktiver werden und die Vorbehalte der KMUs in der Studie bezüglich Clouds und Datenschutz könnten ev. geringer werden und derartige Lösungen interessant werden.

Das LBF ist ein ganzheitlicher Ansatz und beinhaltet technische und organisatorische Aspekte. Im Versuch konnte der generische Teil nicht zu 100% überzeugen und es wäre eine Überarbeitung und ein weiterer, größere Test notwendig. Ebenso sollte die Universal Staging Area nicht für größere Datenmengen benutzt werden, da diese zu erhöhten Laufzeiten führt. Für kleinere und schnelle Anpassungen war das Konzept tauglich.

Das LBF hat aus organisatorischer Sicht interessante Aspekte, welche gut nutzbar sind. Die technischen Aspekte sollten jedoch überarbeitet werden. Nach den bisherigen Gesprächen des Autors und neuen Inputs wäre es interessant auch die Konzepte der bimodalen IT von Gartner, Visualisierungsstandards nach IBCS, eines logischen Datewarehouses (siehe den Artikel von TDWI) und Big Data generell zu betrachten und zu prüfen, welche Aspekte davon für ein Framework brauchbar sind.

Literatur

1. Martens, Benedikt, Walterbusch, Marc und Teuteberg, Frank. Costing of Cloud Computing: A Total Cost of Ownership Approach. 2012

2. McKnight, William. Why Databases are moving to the Cloud. [Online] 2016-10-26

3. Accenture. Cloud-based Hadoop Deployments: Benefits and Considerations. [Online]. 2014.

4. Infor. Examining the security of cloud-based vs. on-premise deployments. [Online]. 2015.

5. Elegant BI. Whitepaper: Making the Choice: Commercial Open Source (COS) vs. Proprietary Business Intelligence (BI). [Online]

6. Schmarzo, Bill. Data Warehousing 101. [Online]. 2013-12-05.

7. Bär, Reinhard und Purtschert, Philippe. Lean-Reporting: Optimierung der Effizienz im Berichtswesen. Wiesbaden : Springer Vieweg, 2014. ISBN 978-3-8348-2292-5.

8. Stodder, David. TDWI Checklist Report: Six Strategies for Accelerating ROI from SELF-Service BI. [Online]. 2017-03.

9. Sauldie, Sanjay. Die Geheimnisse erfolgreicher Websites. s.l. : Books in Demand GmbH, 2010. 978-3-8391-4206-6.2010

10. Doll, William J. und Torkzadeh, Gholamreza. The Measurement of End-User Computing Satisfaction. MIS Quarterly. Volume 12, Issue 2, pages 259-274, 1988.

11. Dedić, Nedim und Stanier, Claire. Measuring the success of changes to Business Intelligence solutions to improve Business Intelligence reporting. Journal of Management Analytics, Volume 4, Issue 2, pages 1 - 15. 2017.

12. Gartner. Gartner Hype Cycle for Business Intelligence and Analytics 2015 . [Online]. 2015

 

Über den Autor

Markus Rotter, MA ist seit den 2000ern in der IT tätig und hat in dieser Zeit Erfahrungen mit IT-Management, Business Intelligence, Datawarehousing, Datenbanken, Systemadministration, IT-Architekturen, Mitarbeiterführung und Projektmanagement gemacht.

Zurück

Übersicht der Artikel

Dieser Artikel beschreibt eine Vorgangsweise, um mittels eines Leuchtturmprojekts ein Keyuserkonzept voranzutreiben.

Weiterlesen

Dieser Artikel beschreibt die Definition von Kennzahlen im Rahmen eines BICC.

Weiterlesen

Dieser Artikel beschreibt die Anwendung eines kontinuierlichen Verbesserungsprozesses.

Weiterlesen

Dieser Artikel beschreibt die Sicherstellung der Effektivität und Effizienz des Arbeitens mit Daten durch ein Business Intelligence Competency Center (BICC)

Weiterlesen