QlikView für SAP-Benutzer - cdn.crn.decdn.crn.de/fileadmin/whitepapers/files/qliktech_deutschland... · ABAP-Programmen benutzt wird. Alternativ kann auch ein ODBC-Treiber genutzt

STRATEGY PARTNERS INTERNATIONAL COPYRIGHT 2005

Chasa Ursa Major

CH-7550 Scuol

Schweiz

QlikView für SAP-Benutzer

Whitepaper - Version D 1.0

November 2005

Helmuth Gümbel - Managing Partner

Strategy Partners International

Chasa Ursa Major

CH-7550 Scuol

[email protected]

Text und Abbildungen wurden mit größter Sorgfalt erarbeitet. Der Autor übernimmt jedoch für eventuell verbliebene fehlerhafte Angaben und deren Folgen keine Haftung.

Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte insbesondere die der Übersetzung, des Nachdrucks, der Entnahme der Abbildungen, der Funksendung, der Wiedergabe auf fotomechanischen oder ähnlichem Wege und der Speicherung in Datenverarbeitungsanlagen bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten.

SAP, R/3, mySAP und NetWeaver sind Marken und Warenzeichen der SAP. QlikView und QlikTech sind Marken von QlikTech International AB.



Inhaltsverzeichnis

Ziel dieses White Papers .......................................................................1

Zusammenfassung für das Management..............................................2

Die besondere Lage der SAP-Kunden..................................................4

Was möchte ein SAP-Benutzer?...........................................................6

Eine Lösung: QlikView.........................................................................7

Wie verträglich ist QlikView mit der SAP-Architektur? ................. 13

Wann ist QlikView für den SAP-Anwender interessant? ................ 13

Wann ist der Einsatz von QlikView weniger sinnvoll?................... 14

Fazit ..................................................................................................... 15

Abbildungsverzeichnis ....................................................................... 16

Strategy Partners InternationalS


Ziel dieses White Papers

Mit diesem Papier wollen wir CIOs wichtige Hintergrundinformationen zur

Verfügung stellen, um Investitionsentscheidungen für Software-Ergänzungen

im SAP-Umfeld zu erleichtern. Im Falle von QlikView geht es hier ganz

speziell um die Frage, wann sich eine Investition in solche Software empfiehlt

und wie sie angesichts der SAP-NetWeaver-Strategie zu beurteilen ist, die ja

bekanntlich neben einem breiten Middleware-Angebot auch Funktionen im

Bereich der Business Analytics beinhaltet.


STRATEGY PARTNERS INTERNATIONAL COPYRIGHT 2005 2S

Zusammenfassung für das Management

In einer Zeit, in der sich der Informationsbedarf ständig ändert und kein

Mangel an Daten, aber dafür an Information herrscht, ist das Interesse an

analytischen Werkzeugen ständig gestiegen. Leider musste man aber oft

feststellen, dass der Weg zu schneller und einfach zu verstehender

Information schwierig, kompliziert und teuer ist. Die Daten stammen oft aus

sehr unterschiedlichen Systemen und selbst dann, wenn ein Unternehmen sich

auf einen Anwendungshersteller wie SAP festgelegt hat, ist die Landschaft

wegen verschiedener Releasestände sehr heterogen.

SAP hat ein Business Intelligence Produkt als Bestandteil seiner

Produktpalette. Oft aber mussten Anwender feststellen, dass dieses Werkzeug

sich zwar für viele Analysezwecke und auch das Errichten komplexer Data

Warehouses eignet, aber sehr langwierige und auch teure Vorarbeiten

notwendig macht. QlikView ist hier eine Alternative, die immer dann attraktiv

ist, wenn man Daten analysieren will ohne den Aufbau eines komplexen Data

Warehouses oder zumindest eines Data Marts zuerst vornehmen zu müssen.

Ein Anwender berichtet: „Mit QlikView haben wir in 1 ½ Tagen 80% der

Anforderungen umgesetzt, die wir mit SAP BW in 1 ½ Jahren vergeblich zu

realisieren versucht haben“.

QlikView benutzt eine patentierte Technologie, die sehr schnell ist und auch

sehr große Datenmengen bewältigt.

Neben wichtigen Cost-of-Ownership-Vorteilen ist besonders hervorzuheben,

dass QlikView

• weder erzwingt, dass man der vorgeschlagenen SAP-

Migrationsstrategie Richtung NetWeaver folgt

• noch eine Behinderung bei einem solchen Weg darstellt und

• keine Vorauswahl bezüglich der Middleware-Technologie-Stacks

darstellt.

Damit können Entscheidungen im Bereich Analytics bei der Wahl von

QlikView deutlich von strategischem Ballast befreit werden, weil nämlich



eine günstige Kostensituation auch eine schnelle Amortisation verheisst. Aus

diesem Grunde empfehlen wir, QlikView immer dann in die Wahl zu ziehen,

wenn man nur Analytics braucht, ein Data Warehouse (noch) nicht braucht

und neben sehr guter Leistung auch Gestaltungsfreiheit beim künftigen

Anwendungs- ausbau bewahren möchte. Selbstverständlich kann man aber

auch QlikView in einer Data Warehouse-Umgebung einsetzen.



Die besondere Lage der SAP-Kunden

Auf der Sapphire 2005 in Boston erklärte SAP CEO America, Bill

McDermott: "Clients have made their choice. Best of breed is gone." Dieser

Satz war zwar auf den inzwischen von Oracle erworbenen CRM-Mitbewerber

Siebel gemünzt, zeigt aber auch ganz allgemein, dass SAP glaubt, mit seiner

sehr breiten Produktpalette alle Fälle abdecken zu können.

Tatsächlich ist aber in kaum einer SAP-Installation ausschließlich SAP-

Software zu finden, nicht einmal in jenen Funktionsbereichen, die mit SAP-

Software gut abdeckbar sind. SAP hat bei seinen Kunden heute nur im Mittel

eine Durchdringung von etwas über 50%. Der Rest wird mit anderen

Anwendungen abgedeckt.

Das hat viele Gründe, die aber alle auf einen Punkt hinauslaufen: Anwender

wählen immer die Lösungen, die im Moment für sie unter Abwägung aller

Kriterien am geeignetsten sind.

• Abbildung 1: Alte SAP Versionen dominieren im Feld



Andererseits hat SAP sehr vielen Kunden komplette mySAP-Software-Suiten

verkauft. Über 50% der SAP Kunden haben solche Lizenzverträge, aber sie

setzen immer noch mit beeindruckender Mehrheit alte Versionen ein. SAP

versucht das Auslaufen der Wartung Ende 2006 als “Migrationshebel” zu

nutzen, aber viele Kunden werden sich auch hierdurch nicht von ihrem

Vorhaben abbringen lassen, zuerst an ihr Geschäft zu denken und erst dann

die Vorschläge der Software-Lieferanten zu prüfen.

Die Anwendungslandschaft wird auch bei über 80% der SAP-Kunden

heterogen bleiben. SAP-Kunden mit mehreren Installationen haben oft

unterschiedliche Versionen im Einsatz, die nicht einfach und kostengünstig

auf neue Versionen umzustellen sind. Aus historischen und finanziellen

Gründen werden immer noch ältere Anwendungen betrieben, die funktional

befriedigen, aber nicht dem Anspruch an ein einheitliches technologisches

Konzept, so wie es von SAP postuliert wird, genügen. Unternehmenskäufe

und die immer wichtiger werdenden unternehmensübergreifenden

Kollaborationen bringen immer wieder andere Anwendungselemente in das

Portfolio.

Auf der einen Seite möchte man schnell und unkompliziert eine einheitliche

Sicht auf die Unternehmensdaten gewinnen, kann aber die entsprechenden

Systeme nicht einfach, risikolos, zeitgerecht und billig auf eine einheitliche

Plattform migrieren.

Eine solche Migration würde auch die Abhängigkeit von einem Hersteller

(und damit auch von seiner Entwicklungsgeschwindigkeit und Marktmacht)

vergrößern, was vielen Anwendern nicht angenehm erscheint.

Es ergibt sich also das Dilemma, dass man einerseits eine immer schneller

steigende Notwendigkeit zu schnellen Datenanalysen feststellt, andererseits

die dafür ideale Zusammenführung aller relevanten Daten in ein einheitliches

System immer weniger schafft.

Welche Anforderungen stellt ein SAP-Anwender an ein modernes

Analysetool?



Was möchte ein SAP-Benutzer?

Die meisten SAP-Installationen haben bereits ein breites Spektrum von

Analysewerkzeugen, die aber, wie etwa Microsoft Excel, zwar in ihren

Grundlagen schnell erlernbar sind, aber bei stärkerer Beanspruchung doch

rasch Leistungsgrenzen zeigen. Zudem hat sich das, was früher als Freiheit

der Wahl gepriesen wurde, heute oft in ein schwer zu ordnendes Chaos

entwickelt. In vielen Firmen ist es kaum nachvollziehbar, wie und mit

welchem Werkzeug jene Daten entstanden, die „nur“ der

Entscheidungsunterstützung dienen. Die meisten Benutzer wollen:

• Ein schnell erlernbares Werkzeug, das bereits nach wenigen Tagen Resultate bringt. Leichte Benutzbarkeit soll eine intuitive Arbeitsweise erlauben und keine Datenmodellkenntnisse erfordern

• Kurze Implementierungszeiten, um rasch ein Erfolgserlebnis zu haben

• Eine Lösung, bei der sie nicht erst abwarten müssen, was sich am Ende einer mehrjährigen SAP-Migrations- und Upgrade-Planung ergibt

• Die Flexibilität, völlig frei unter den verschiedensten Datenquellen wählen zu können, auch ältere SAP_Versionen – und, natürlich, ohne versteckte Kosten

• Architektonische Sicherheit, die auch bei einer späteren unternehmensweiten SAP-BW-Einführung eine weitere Nutzung sichert

• Hohe Analysegeschwindigkeit, die angesichts der meist rapide anwachsenden Datenbestände auch langfristig gesichert ist

• Eine Lösung, die geringe Anforderungen an die Infrastruktur stellt. Dazu gehört auch die Datenbankunabhängigkeit

• Business Analytics, die ohne große Vorleistungen implementierbar sind

• Nachvollziehbare und wiederholbare Analysen. Die meisten Analysen dienen der Entscheidungsfindung. Da generell eine bessere Rückverfolgbarkeit von Entscheidungen auf allen Ebenen gefordert wird (etwa durch gesetzliche Vorschriften wie Sarbanes-Oxley, aber auch in der Qualitätssicherung wie etwa Six Sigma oder ISO), will man oft wissen, wie ein Analyse-Ergebnis zustande kam.

• Unabhängigkeit von den Technologie-Stacks der Hersteller (NetWeaver, WebSphere, .NET…)

• Einen Hersteller, der ihnen Business Intelligence nicht als Lockvogel für andere Anwendungen anbietet, sondern der sich mit seiner ganzen Substanz genau für dieses Thema einsetzt.

• Eine Lösung, die in der Anschaffung und im Betrieb preiswert und überschaubar ist und bleibt.



Eine Lösung: QlikView

Wenn man nämlich akzeptiert, dass die heute zu beobachtende heterogene

Anwendungs- und Datenlandschaft nicht eine vorübergehende Situation ist,

sondern dauerhafte Realität sein wird, die dazu auch noch einem im Detail

kaum zu prognostizierendem Wandel unterliegt, dann werden anwendungs-

und datenquellen-unabhängige Analysewerkzeuge plötzlich sehr attraktiv. Sie

postulieren nicht eine kaum herzustellende Einheitlichkeit. SAP als

Anwendungshersteller hat, wie oben dargestellt, ein großes Interesse, seine

Kunden zum Umstieg auf neue Versionen zu bewegen und bietet daher nur

sehr begrenzt Lösungen an, die neue SAP-Software auch in älteren

Umgebungen ablaufen lassen und somit den Migrationsdruck mindern.

Ein unabhängiger Hersteller wie QlikTech hat dieses Problem nicht. Für ihn

sind alle Anwendungs- und Datensysteme gleich – unterstützt wird, was der

Kunde wünscht. Das QlikTech Produkt QlikView passt sich an – es enthält

integrierte Datenextraktionswerkzeuge, die nicht nur den Zugriff auf SAP

Systeme erlauben, sondern auch den Zugriff auf das Business Warehouse von

SAP gestattet. Daneben werden viele andere Anwendungssysteme unterstützt

und natürlich ist der Zugriff auch auf Daten selbst geschriebener

Anwendungen möglich.

Wie erfüllt QlikView nun die oben aufgestellten Anforderungen?

Schnelle Erlernbarkeit. QlikView hat ein dreistufiges Benutzer- und

Rollenkonzept. Der eigentliche Endbenutzer, bei QlikView Analyzer genannt,

braucht nur eine kurze Einweisung, die wenige Minuten dauert. Der

Professional User, der Analysen zusammenstellt, kommt mit zwei Tagen

Schulung aus. Der IT-Experte, als Enterprise User bezeichnet, der alle

systemtechnischen Aspekte abdeckt, braucht Kenntnisse des Datenmodells als

Voraussetzung und ist ebenfalls nach zwei Tagen Ausbildung einsatzfähig.

Zur leichten Erlernbarkeit kommt die leichte Nutzung hinzu: analytische

Anzeigen, hier „Dashboards“ genannt, erlauben eine spontane

Analysevertiefung („Drill-down“) und ein Wechsel in der Betrachtung der

Daten ist jederzeit möglich, ohne die Analyse komplett neu aufzusetzen. So



kann man sich ganz dem „was“ widmen, ohne lange über das „wie“

nachdenken zu müssen.

Rasche Implementierung erlaubt schnelle Erfolge. QlikView ist innerhalb

weniger Tage implementiert und nutzbar. Damit stellen sich rasch erste

Erfolge ein. Die Benutzerakzeptanz steigt und man kann zügig aus den ersten

Resultaten lernen.

Unabhängigkeit von der SAP-Migrations- und Upgrade-Planung. Da

QlikView praktisch unabhängig ist von der SAP-Infrastruktur bestehen auch

keine Abhängigkeiten von irgendwelchen Migrations- oder Umstellungs-

planungen. Beispielsweise braucht man nicht zu warten, bis z.B. ein Business-

Warehouse aufgebaut ist oder mySAP ERP eingeführt wurde, behindert mit

QlikView aber solche Pläne auch nicht. Hierdurch wird ein oft als sehr

unangenehm empfundener Druck aus der Planung genommen.

Freie Wahl der Datenquellen. QlikView ist im Prinzip für alle erdenklichen

Datenquellen geeignet. Es bietet den Zugriff auf relationale Datenbestände via

ODBC, auf multidimensionale Datenbanken mittels OLE DB sowie auf

weitere strukturierte Quellen wie Text-, Excel- und XML-Dateien. Das

gestattet dann auch den Zugriff auf ERP-Systeme der verschiedensten

Hersteller wie etwa SAP, Intentia/Lawson, Oracle oder Microsoft. Dabei gibt

es auch keine versteckten Kosten und auch keine unangenehmen

Überraschungen, denn eine Nachvermessung oder Datenvolumen-abhängige

Gebühren gibt es bei QlikView nicht. Anders als beim SAP BW braucht man

auch kein teures OpenHub, um Daten mit anderen Systemen auszutauschen.

QlikView erlegt dem Benutzer hier keinerlei Beschränkungen auf – schon gar

nicht, indem zusätzliche Lizenzkosten und Wartung für die Nutzung der

Offenheit erhoben werden.

Architektonische Sicherheit. QlikView kann direkt auf SAP-Daten

zugreifen und bedient sich dabei einer Schnittstelle, die auch von vielen

ABAP-Programmen benutzt wird. Alternativ kann auch ein ODBC-Treiber

genutzt werden. Anwender, die bereits ein SAP BW betreiben oder ein BW

einrichten wollen, müssen nicht auf QlikView verzichten. QlikView kann

auch das BW als Datenquelle nutzen. Mit QlikView bleibt daher auch eine

BW-Strategie möglich – man verbaut sich nichts.



Hohe Analysegeschwindigkeit. QlikView benutzt eine patentierte

Technologie, bei der an Stelle einer Datenbank der Hauptspeicher benutzt

wird. Neben einer extremen Beschleunigung ergeben sich auch noch ganz

andere Vorteile: da alle Daten quasi assoziativ erreichbar sind, ist eine ganz

neue Freiheit bei der Gestaltung und Umgestaltung von Analysen möglich.

Der Blick in die Daten ist nicht mehr von einem Datenschema abhängig und

man braucht daher auch als Benutzer keine Kenntnisse von einem solchen

Schema zu haben. Da die Daten beim Einlesen auch stark verdichtet werden,

schrumpfen auch sehr grosse Datenbestände. So können über 200 Millionen

Datensätze aus einem 15 TB großen Data Warehouse, wie in einem

praktischen Einsatzfall gezeigt, auf 4 GB Hauptspeicher abgebildet werden.

Damit können auch auf längere Sicht selbst sehr grosse und rasch wachsende

Datenbestände mit dieser Technologie analysiert werden. Manchmal ist das

sogar die einzige Möglichkeit, in akzeptabler Zeit zu den gewünschten

Analysen zu gelangen.

Geringe Anforderungen an die Infrastruktur. QlikView stellt sehr

bescheidene Anforderungen an seine Umgebung. Je nach Produkteinsatz

(QlikView, QlikView Server oder Publisher) braucht man einen gut

ausgestatteten PC und entsprechend viel Speicher, der heute nicht mehr viel

kostet. Da QlikView aber alle Analysen im Hauptspeicher durchführt, braucht

man keine Datenbank. Wer viele Benutzer hat, die auf die gleichen Daten

zugreifen, der kann mit einem oder mehreren QlikView Servern die

Anforderungen für die Endbenutzer PCs weiter reduzieren. Da man keine

zusätzliche Datenbank braucht, entfallen auch Administrations- und Backup-

Kosten sowie Upgrades für die Datenbanksoftware. Unliebsame

Überraschungen, wie sie etwa die Oracle-Benutzer durch die jüngsten

Umstellungen des Lizenzmodells erfahren haben, gibt es nicht – was nicht da

ist, kostet weder Wartung noch Lizenzen. Der große Hauptspeicher wird

einmal angeschafft und bedarf danach keiner Pflege oder Aufmerksamkeit.

Geringe Vorleistungen. QlikView braucht kaum Infrastruktur und das nötige

Know-how ist schnell erworben. Man kann die Lizenzen exakt so

konfigurieren, wie man es benötigt – es gibt keinen „Lizenzproporz“, der

verlangt, dass man nur in geringem Umfang billigere Benutzer konfigurieren

kann. Anwendungen können in kurzer Zeit erstellt werden, weil die



Oberfläche leicht zu begreifen ist und man auch mehrdimensionale

Funktionen ohne Wissen der ursprünglichen Datenstrukturen nutzen kann.

Wissen über die Datenstrukturen eines Data Warehouses ist entbehrlich, weil

QlikView durch seine patentierte in-Memory Technologie die Daten aus Sicht

des Anwenders „strukturlos“ behandelt. QlikView ist auch in der Lage, Visual

Basic oder Java Macros zu nutzen und kann damit auch weit verbreitete

Programmierkenntnisse einbringen, falls eine Erweiterung der

Standardfunktionen notwendig ist.

Nachvollziehbarkeit. QlikView unterstützt ein „Bookmark“-Konzept, mit

dem Analysen nachvollziehbar werden und auch wiederholt werden können.

Wenn gewünscht, können mehrere Benutzer diese Bookmarks gemeinsam

nutzen. Das Bookmark-Konzept ist auch für Reports nutzbar, um vom

Verfahren her gleich bleibende Routine-Reports zu ermöglichen.

Unabhängigkeit von den Technologie-Stacks der Hersteller (NetWeaver,

WebSphere, .NET…). Zwischen den marktmächtigen Anbietern dieser

Stacks ist ein Kampf um Marktanteile entstanden, der für die Anwender

wenig produktiv ist, weil das Ende schwer abzusehen ist. Der Anwender ist

aber am besten gestellt, wenn er möglichst wenige Abhängigkeiten hat, weil

er dann am flexibelsten konfigurieren kann. QlikView kann in allen diesen

Umgebungen genutzt werden und auch aus ihnen Daten gewinnen

Business Intelligence als Kerngeschäft. Anwendungsanbieter, die Business

Intelligence Funktionen in ihrem Portfolio haben, versuchen in erster Linie

damit, ihre Anwendungen attraktiver zu machen. Das drückt sich gelegentlich

auch in der Preisgestaltung aus: BI wird dann „kostenlos“ in das

Anwendungspaket integriert. Man muss aber hier genau aufpassen, denn der

Anwendungshersteller kann jederzeit seine Preissysteme verändern und damit

auch bereits installierte Systeme treffen und er tendiert dazu, auch vom Preis-

und Geschäftsmodell den Kunden so zu beeinflussen, dass er möglichst

innerhalb des Portfolios des Anwendungsherstellers bleibt. Bei einem „pure

play“ BI-Anbieter wie QlikTech gibt es diese Situation nicht, denn er hat sich

voll auf das BI-Geschäft konzentriert. Je mehr Anwendungen, auch

unterschiedlicher Anbieter einbezogen werden, desto mehr kann ein solcher

Hersteller den Anwender von seiner neutralen Integrationskraft überzeugen.



Lock-in auf ein bestimmtes Anwendungportfolio ist überhaupt nicht im

Interesse eines „pure play“-Anbieters. Damit bleibt auch das Geschäftsmodell

durchschaubar.

Preiswert in der Anschaffung und im Betrieb. Ein Data Warehouse ist

keine ganz billige Angelegenheit. Ungefähr zwei Drittel der Kosten eines SAP

BW sind für Endbenutzerunterstützung, Implementierung und Upgrades

aufzuwenden. Auch versierte SAP-Partner, die schon eine Reihe von BW-

Implementierungen erfolgreich absolviert haben, gehen von einem Richtwert

von ca. 50000 Euro für die Einrichtung eines Analyse-„Cubes“ aus. Bei einer

100 Benutzer-Konfiguration eines SAP-BW muss man mit ca. 800 Euro pro

Benutzer und Monat (auf der Basis des fünf Jahre Vollkostenmodells von

Strategy Partners) rechnen. In den meisten Fällen, in denen ein Data

Warehouse eingerichtet wird, braucht man aber „nur“ die Analysefunktion,

die mit QlikView sowohl von der Anschaffung als auch vom laufenden

Betrieb her wesentlich billiger realisiert werden kann.

Bereits ab einem Budget von 20000 Euro für Anschaffung und

Implementierung kann man mit QlikView starten, während man für SAP BW

besser mit Budgets jenseits der 500000 Euro-Grenze rechnet. Nach ein bis

zwei Wochen laufen bereits wichtige Anwendungen, die Installation selbst

benötigt einschliesslich des SAP-Konnektors nur einen halben Tag.

• Abbildung 2: Kostenverteilung über 5 Jahre auf Basis des SPI-Kostenmodells (Durchschnitt bei 10 SAP BW Kunden; Quelle: SPI)

DWH Cost Structure

Hardware and Communications

13%

DWH-Software13%

Other Software0%

Implementation and ongoing upgrades

28%

End-User Costs35%

Rest2%Operation/Administration

9%



Mit QlikView kann der Benutzer aber auch die Nutzung seiner SAP-Lizenz

optimieren. SAP begrenzt nämlich die Anzahl der Informationsbenutzer auf

15% der Gesamtbenutzer. Das reicht oft nicht und man muss dann teurere

Benutzertypen lizensieren. Das erübrigt sich mit QlikView.



Wie verträglich ist QlikView mit der SAP-Architektur?

QlikView kann die verschiedenen, auf dem Markt befindlichen Konnektoren

eingesetzt werden, die oft auch bereits von den Kunden eingesetzt werden.

Alternativ kann man den QlikView SAP-Connector benutzen, der auf einem

RFC beruht und der SAP Daten mittels ODBC an QlikView übertragen kann.

Es werden keine Daten auf die SAP-Datenbank zurückgeschrieben.

Diese beiden Schnittstellen sind die einzigen, die QlikView mit der SAP-

Software verbindet. Insbesondere ist der Kunde nicht gezwungen, NetWeaver

komplett oder mit einzelnen Komponenten einzuführen.

Wie schon erläutert, ist auch das SAP BW, eine Komponente des

NetWeavers, keine Voraussetzung für QlikView. Das BW ist aber auch kein

Hindernis – QlikView kann sofort oder auch später auf ein BW aufgesetzt

werden.

QlikView verträgt sich mit der SAP R/3 Umgebung genauso wie mit mySAP

ERP oder mySAP Business Suite. Sollte SAP später gezwungen sein, einmal

das Datenmodell zu ändern, ist QlikView natürlich auch davon betroffen –

aber auch nicht mehr, als Hunderttausende von SAP-Anwendungen.

Wann ist QlikView für den SAP-Anwender interessant?

QlikView ist immer dann für SAP-Benutzer interessant, wenn es sich um

Datenanalysen dreht, die schnell, unkompliziert, preiswert und mit grosser

Ablaufgeschwindigkeit zu erstellen sind. Da die Abhängigkeiten von der

SAP-Architektur gering sind und man mit jedem auf dem Markt befindlichen

Release ab 4.6C arbeiten kann, braucht man auch auf die oft sehr komplizierte

Planung für die weitere Entwicklung der SAP-Landschaft keine Rücksicht zu

nehmen.

Mit QlikView behält man auch die Option eines späteren BW-Einsatzes

ebenso, wie die Freiheit, unter den Middleware-Stacks zu wählen. Man ist

weder auf NetWeaver festgelegt noch dagegen.



Wann ist der Einsatz von QlikView weniger sinnvoll?

Es gibt auch Situationen, in denen der Einsatz QlikView weniger sinnvoll ist.

Sie lassen sich in drei Kategorien einteilen.

1. Analyse-Ergebnisse müssen in den Anwendungsdatenbestand zurück

geschrieben werden. Erfordert der Einsatzfall, dass die Analyse-

Ergebnisse wieder in die SAP-Umgebung als Input für eine Anwendung

zurück übertragen werden müssen, so ist QlikView nicht das geeignete

Werkzeug. Selbstverständlich können aber Berichte, die mit QlikView

erstellt werden, über Portale verteilt werden. Auch das SAP Portal ist

hierfür geeignet.

2. Es soll ein Enterprise Data Warehouse errichtet werden oder zumindest

ein Data Mart. QlikView ist für diese Art der Anwendung nicht

geschaffen, weil sie eine Datenbank voraussetzt. QlikView kommt ohne

die umfänglichen Infrastrukturvorleistungen eines Data Warehouse aus

und nutzt stattdessen eine patentierte Hauptspeichertechnik für seine

Analysen, die damit besonders schnell und für den Benutzer auch einfach

durchführbar sind. Man kann aber durchaus QlikView auf dem SAP

Business Warehouse aufsetzen und hat, wenn man unbedingt ein Data

Warehouse braucht, dann die Möglichkeit, die Vorzüge von QlikView

auch in einer solchen Umgebung nicht aufgeben zu müssen.

3. Anwendung oder Hersteller verlangen ein anderes Produkt. Es ist klar,

dass z.B. SAP analytische Funktionen immer auf dem eigenen Produkt

aufsetzen wird, weil SAP an dessen Verbreitung ein wirtschaftliches

Interesse hat. Anwendungen, die für eine bestimmte analytische

Zielumgebung geschrieben sind, funktionieren ebenfalls nur mit der

Zielumgebung. QlikView ist hierfür schon von der Produktauslegung, die

auf den spontanen Endbenutzer hin optimiert wurde, nicht geeignet.

Aber auch in diesen Situationen muss man aber nicht gänzlich auf QlikView

verzichten, weil QlikView auch neben oder „auf“ einem SAP BW eingesetzt

werden kann.



Fazit

Wenn es sich um unkomplizierte, schnelle, kostengünstige Analytics dreht,

bei denen die einfache (und daher auch langfristig kostengünstige)

Handhabung wichtig ist, sollte man unbedingt QlikView als Alternative in

Betracht ziehen. Die Unabhängigkeit von der SAP Strategie ist hier von

Vorteil: man gewinnt dank der schmalen Schnittstellen die Option, vom

Migrationsdruck des Anwendungsherstellers unabhängig zu werden. Die

Option, auch das SAP BW nutzen zu können, beruhigt – man kann, aber man

muss nicht. Leider eine heute selten gewordene Flexibilität.



Abbildungsverzeichnis

Abbildung 1: Alte SAP Versionen dominieren im Feld....................................................................................4 Abbildung 2: Kostenverteilung über 5 Jahre auf Basis des SPI-Kostenmodells bei 10 SAP BW-Kunden

(Quelle: SPI) ...................................................................................................................................11

Documents

QlikView für SAP-Benutzer - cdn.crn.decdn.crn.de/fileadmin/whitepapers/files/qliktech_deutschland... · ABAP-Programmen benutzt wird. Alternativ kann auch ein ODBC-Treiber genutzt