Standardisierte Performance-Optimierung von arcplan ... · PDF fileSAP BW-Entwickler wissen, wohin der Fachbereich „fahren“ möchte, der arcplan-Entwickler sollte verstehen, was

Braincourt GmbH, Fasanenweg 11, 70771 Leinfelden-Echterdingen, T +49 711 75 85 80 0, F +49 711 75 85 80 80, [email protected]

Niederlassung Düsseldorf: Mörsenbroicher Weg 200, 40470 Düsseldorf, T +49 211 87 74 20 0, F +49 211 87 74 20 11, [email protected]

Marc Schlipphak, Senior Manager Manuel Schlereth, Manager

Braincourt GmbH

Corporate Performance Management

10 mal schnellere Antwortzeiten von arcplan Standardisierte Performance-Optimierung von arcplan-Anwendungen

in SAP BW-Umgebungen

Seite 2

© Braincourt GmbH. Alle enthaltenen Beiträge und Abbildungen sind urheberrechtlich geschützt. Kopieren oder Nachdruck sind verboten. Ausnahmen nur mit ausdrücklicher

Genehmigung. Das Zitieren von Auszügen kann nur gestattet werden, wenn Braincourt GmbH als Quelle genannt wird. Kontakt: Braincourt GmbH, Tel. +49 711 758580-0, [email protected]

Inhaltsverzeichnis

1 Einleitung ....................................................................................................................................................... 3

2 Typische Ausgangssituation und ihre Entstehungsgeschichte ....................................................................... 4

3 Fünf Ansatzpunkte zur Performance-Optimierung ........................................................................................ 6

3.1 Zusammenarbeitsmodell ..................................................................................................................... 6

3.2 Technische Ansatzpunkte .................................................................................................................... 7

3.2.1 Daten Layer ............................................................................................................................ 8

3.2.2 Business Layer ........................................................................................................................ 9

3.2.3 Frontend Layer ....................................................................................................................... 9

3.2.4 Consumer Layer.................................................................................................................... 10

4 Vorgehen im Performance Optimization Package ....................................................................................... 11

5 Ihre Ansprechpartner .................................................................................................................................. 13

Seite 3



1 Einleitung Sind Sie bzw. die Endanwender in Ihrem Unternehmen zufrieden mit den

Antwortzeiten Ihrer, auf SAP BW basierenden, arcplan-Anwendung(en)?

Wenn Sie die Frage mit einem „Sehr.“ oder „Ganz okay.“ beantworten können,

dann lehnen Sie sich jetzt entspannt zurück. Beantworten Sie die Frage aber mit

einem „Gerade noch so.“ oder vielleicht einem „Nein.“, dann seien Sie insofern

beruhigt, dass Sie bei Weitem kein Einzelfall sind und Sie mit diesem Artikel

spannende Erkenntnisse gewinnen werden!

Die nachhaltige Akzeptanz von BI-Applikationen ist maßgeblich von deren Perfor-

mance abhängig. Endanwender kommen zunehmend aus der „Generation Y“1

und sind Antwort- und Reaktionszeiten im niedrigen, einstelligen Sekundenbe-

reich gewohnt. Antwortzeiten von über zehn Sekunden sind für diese „Digital

Natives“ oftmals nicht akzeptabel. BI-Applikationen dagegen müssen mit einer

immer größeren Datenmenge umgehen können. „Big Data Analytics“, „Predictive

Analytics“ und „Data Discovery“ sind laut der aktuellen BARC-Studie „The BI-

Survey 2014“ geplante Einsatzgebiete in vielen Unternehmen. Dem Aspekt der

Performance kommt also eine stetig wachsende Bedeutung zu.

Braincourt hat in den letzten Jahren Erfahrungen in über 25 arcplan Projekten

sammeln dürfen. Insbesondere in SAP BW-Umgebungen sind die Performance-

Probleme von arcplan-Anwendungen fast immer auf die gleichen Ursachen

zurückzuführen. Für diese Ursachen gibt es größtenteils sehr einfache Optimie-

rungsansätze. So bietet Braincourt Ihnen für die Analyse und Optimierung beste-

hender arcplan-Anwendungen das sogenannte Performance Optimization

Package an: Ein standardisiertes Vorgehen mit garantiertem Erfolg zum Festpreis.

Der vorliegende Artikel möchte Ihnen nun einen Einblick in die Inhalte des Ange-

botes geben. Aufgrund der Erfahrungen der Braincourt Berater und dem Einsatz

einer strukturierten Methodik, sind Performancesteigerungen um mehr als 90%

bei überschaubarem Aufwand keine Seltenheit.

In diesem Artikel wird zunächst eine typische Ausgangssituation und ihre Ent-

stehungsgeschichte beschrieben, wie sie erfahrungsgemäß anzutreffen ist, wenn

der Wunsch nach einer Performance-Optimierung besteht. In Kapitel drei wer-

den die wesentlichen Ansatzpunkte zur Performance-Optimierung auf Basis der

Projekterfahrungen von Braincourt im Sinne einer Best Practice dargestellt. Im

abschließenden Kapitel 4 wird das konkrete Vorgehen im Performance

Optimization Package erläutert.

1 Laut Wikipedia wird als Generation Y in der Soziologie diejenige Bevölkerungskohorte genannt, deren Mitglie-der um das Jahr 2000 herum zu den Teenagern zählten. Je nach Quelle wird diese Generation auch als Millennials oder Digital Natives bezeichnet. [Quelle: https://de.wikipedia.org/wiki/Generation_Y]

Spannende Erkenntnisse er-

warten Sie in diesem Artikel,

wenn Sie mit der Performance

Ihrer arcplan-Anwendungen

basierend auf SAP BW gerade

noch so oder gar nicht zufrie-

den sein sollten.

Die Generation Y und zukünf-

tige Themen, wie Big Data

Analytics, Predictive Analytics

oder auch Data Discovery wer-

den noch höhere Ansprüche

an die Performance stellen.

Braincourt GmbH: Sehr viel Er-

fahrung mit arcplan aus über

25 arcplan-Projekten.

Seite 4



2 Typische Ausgangssituation und ihre Entstehungs-

geschichte Was sind die Ursachen für unzureichende Antwortzeiten einer arcplan-Anwen-

dung in einer SAP BW-Umgebung? Aus den Reihen der Fachabteilung hört man

oft, das würde definitiv an SAP BW liegen. Die IT-Abteilung und die SAP-Entwick-

ler wiederum sehen die arcplan-Anwendungen meist außerhalb ihres Einfluss-

und Aufgabenbereiches. Eine vom Fachbereich ausgewählte und betriebene 3rd-

party Technologie wird von Ihnen ohnehin gerne als „Dorn im Auge“ gesehen.

Letztendlich aber helfen weder Diskussionen über Zuständigkeiten noch gegen-

seitige „Schuldzuweisungen“ weiter.

Die Gründe für langsame Antwortzeiten sind vielfältig. Grundsätzlich jedoch

können die wesentlichen Ursachen zwei Kategorien zugeordnet werden. Zum

einen ist es das technologische Zusammenspiel von SAP BW und arcplan. Dies

betrifft alle Aspekte der konkreten technischen Ausgestaltung der Schnittstellen

zwischen arcplan und SAP BW. Diese können unterschiedlich realisiert werden

und sind häufig nicht mit dem Ziel einer maximalen Performance gestaltet. Zum

anderen sind die Ursachen für Performance-Probleme oft organisatorischen

Ursprungs, liegen also in der Zusammenarbeit zwischen arcplan- und SAP BW-

Entwicklern.

Wie entsteht nun eine arcplan-Anwendung in Unternehmen üblicherweise? Der

grundsätzliche Bedarf für eine neue BI-Anwendung kommt aus den Fach-

bereichen. Die fachlichen Anforderungen sind dann die Grundlage für die Tech-

nologieentscheidung, die entweder auf Basis einer bestehenden IT- bzw. BI-

Strategie oder eines strukturierten Auswahlprozesses getroffen wird. Das Resul-

tat, die tatsächlich zum Einsatz kommende Technologie, ist in aller Regel stark

vom Verhältnis der IT-Abteilung zum anfordernden Fachbereich geprägt. Ist die

Entscheidung auf die Technologie arcplan gefallen – laut eingangs erwähnter

BARC-Studie ist dies bei 3rd-party Frontends auf SAP BW seit zehn Jahren der

häufigste Fall, werden die entsprechenden Anwendungen in aller Regel von

„IT-affinen“ Mitarbeitern in den Fachbereichen realisiert. Die für diese Anwen-

dung benötigten Daten kommen aus dem zentralen Data Warehouse, also meist

aus SAP BW. So werden die SAP-Entwickler gebeten, die benötigten Daten zu

liefern. Die zentrale IT-Abteilung wiederum hätte vielleicht lieber ein SAP Front-

end eingeführt und schon hakt es in der Zusammenarbeit und der technischen

Schnittstelle: Um alle Anforderungen nun schnell und einfach abdecken zu

können, werden den arcplan Entwicklern von der IT-Abteilung oft „große“

Queries mit maximalen Ausprägungen – ohne genaue Kenntnis des tatsächlichen

Bedarfs – auf Basis der bestehenden Modellierung zur Verfügung gestellt. So

kommt es, dass diese Queries viele Merkmale und möglichst alle Kennzahlen auf

granularer Ebene enthalten.

Der Fachbereich wiederum versucht nun diese eine große Query in die arcplan-

Anwendung einzubinden. Bei dieser Vorgehensweise sind Performance-

Probleme vorhersehbar, insbesondere da bei den arcplan-Entwicklern (IT-affine

Die Gründe für langsame Ant-

wortzeiten sind vielfältig.

Die Entstehungsgeschichten

von arcplan-Anwendungen

mit Performance-Problemen

ähneln sich sehr.

Zwei grundsätzliche Ursachen

von Performance-Problemen:

- Realisierung der Schnittstellen

zwischen arcplan und SAP BW

- Zusammenarbeitsmodell

Seite 5



Fachbereichsmitarbeiter) grundlegende IT-Kenntnisse häufig fehlen und keine

ausreichende Unterstützung durch die IT-Abteilung gegeben ist.

Eine so entstandene arcplan-Anwendung generiert – ungeachtet etwaiger

Performanceschwierigkeiten – üblicherweise neue Ideen und weitere konkrete

Anforderungen bei den Endanwendern: Es werden mehr Funktionalitäten und

Daten benötigt. Neue Datenbereiche werden wieder mit „Maximal-Queries“

erschlossen. Unterstützende Funktionalitäten, wie z.B. zur Prozessunter-

stützung, Kommentierung, Berichtsmappengenerierung, Navigation, Parametri-

sierung und Berechtigungssteuerung werden von den arcplan-Entwicklern unter

Ausnutzung der großen Flexibilität der Technologie und dem „Weg des gerings-

ten Widerstandes“ realisiert. Anzutreffen ist bei solchen Lösungen in aller Regel

eine zusätzliche SQL-Datenbank. Dies ist ein technisch gangbarer Weg, dessen

Sinnhaftigkeit allerdings – unter anderem aufgrund von Redundanzen – zu

hinterfragen ist.

Beim Einsatz von Maximal-Queries, historisch gewachsenen Strukturen und nicht

ausreichendem IT-Verständnis der arcplan-Entwickler im Fachbereich sind

Performance-Probleme leider keine Seltenheit: Das Öffnen der Applikation

dauert immer länger, jedes Anklicken eines Filters oder Navigationsschrittes

erzeugt Wartezeiten, Berechnungsergebnisse lassen auf sich warten und die

Anwender werden immer unzufriedener.

Die Beratungspraxis zeigt, dass Antwortzeiten von über eine Minute beim

initialen Aufruf oder pro Navigationsschritt keine Ausnahmen sind. Besonders

ärgerlich ist, dass Akzeptanzprobleme einer arcplan-Anwendung meist nicht auf

inhaltliche oder funktionale Schwächen zurückzuführen sind, sondern auf die

Performance oder eine nicht optimal realisierte Integration in die bestehende

SAP-Umgebung.

Neben den oben bereits erwähnten Maximal-Queries ist ein wesentliches

Performance-Problem immer wieder in der Art und Weise der dynamischen

Filterung zu finden.

Die große Flexibilität von

arcplan wird ausgenutzt:

Funktionsumfang und der aus-

wertbare Datenraum von

arcplan-Anwendungen neh-

men in aller Regel stetig zu.

Sehr lange Antwortzeiten für

Endanwender bei Berichtsauf-

rufen und Navigationsschrit-

ten sind keine Seltenheit. Die

Unzufriedenheit wächst.

Seite 6



Abbildung 1: Typische Ausgangssituation und Problemfelder

Letztendlich führt die Suche nach Ursachen und den „Schuldigen“ für die

Performance-Probleme meist zu einer weiteren Verhärtung der Fronten: Auf der

einen, wie auf der anderen Seite werden im Detail und ohne großen Erfolg meist

ein paar Stellschrauben gedreht. Aber weder das gesamte technologische, wie

auch das organisatorische Zusammenspiel zwischen arcplan und SAP BW werden

analysiert.

3 Fünf Ansatzpunkte zur Performance-Optimierung Zur Verbesserung der Performance haben wir im Wesentlichen das Zusammen-

arbeitsmodell zwischen arcplan- und SAP BW-Entwicklern sowie vier technische

Ansatzpunkte identifiziert: Daten-, Business-, Frontend- und Consumer Layer.

Im Rahmen des Performance Optimization Packages werden diese Ansatzpunkte

sequentiell analysiert. Es ergibt sich ein umfassendes Bild der IST-Situation.

Iterativ werden, basierend auf den gewonnenen Erkenntnissen und einer Kosten-

Nutzen-Einschätzung, die tatsächlich durchzuführenden Maßnahmen definiert

und anschließend exemplarisch umgesetzt.

3.1 Zusammenarbeitsmodell Aufbauend auf den beschriebenen „Maximal-Queries“ lassen sich in aller Regel

die fachlichen Anforderungen an eine arcplan-Anwendung vollumfänglich abbil-

den. Für eine möglichst performante Gestaltung einer Anwendung ist allerdings

ein tieferes Verständnis der jeweiligen technologischen Besonderheiten notwen-

dig. So ist der Aufbau optimierter Objekte in SAP BW für die arcplan-Anwen-

dung(en) genauso unabdingbar, wie ein grundlegendes Verständnis der

arcplan-Entwickler für das Datenmodell in SAP BW. Bildlich gesprochen sollte ein

Es gibt einen organisatori-

schen und vier technische An-

satzpunkte, die zu einer Ver-

besserung der Performance

beitragen können und dem-

entsprechend strukturiert

analysiert werden sollten.

Kenntnis und Verständnis der

technologischen Besonderhei-

ten der beteiligten Technolo-

gien sind elementare Voraus-

setzung für die performante

Realisierung einer arcplan-An-

wendung.

Seite 7



SAP BW-Entwickler wissen, wohin der Fachbereich „fahren“ möchte, der arcplan-

Entwickler sollte verstehen, was sich unter seiner Motorhaube verbirgt und im

übertragenen Sinne auch einen Ölwechsel vornehmen können. Grundlage für

eine Performanceverbesserung ist stets das Aufheben strikter Trennungen von

Verantwortlichkeiten zwischen Frontend und Backend. Bereits in der Konzep-

tionsphase von arcplan-Anwendungen ist es wichtig, dass Fachbereich, IT-

Abteilung, arcplan- und SAP BW-Entwickler eng zusammenarbeiten. Im Ergebnis

sollten eben keine Maximal-Queries entstehen, sondern ganzheitlich für arcplan

optimierte technische Objekte in SAP BW. Dies betrifft, neben der eigentlichen

Modellierung der Stamm- und Bewegungsdaten, insbesondere auch die Realisie-

rung spezieller Funktionsbausteine (siehe hierzu Abschnitt 3.2.3).

Abbildung 2: Vereinfachtes Zusammenarbeitsmodell

3.2 Technische Ansatzpunkte Im Folgenden werden die wichtigsten technischen Performance-Aspekte in

jedem der vier technischen Layer beschrieben und Auszüge typischer Empfeh-

lungen erläutert.

Seite 8



Abbildung 3: Technische Ansatzpunkte des Performance Optimization Package

3.2.1 Daten Layer Der erste Ansatzpunkt für die technische Analyse von Performance-Problemen

sollte immer der Daten Layer sein. Im Daten Layer sind ganz wesentliche Aspekte,

welche die Performance der arcplan-Anwendung beeinflussen, zu finden.

Die erste Frage, die sich beim Daten Layer stellt, ist die nach den im Einsatz be-

findlichen Technologien: Ist ein BW Accelerator oder SAP HANA im Einsatz?

Würde es evtl. unter Performance-Gesichtspunkten Sinn machen, SAP HANA

oder Alternativen, wie z.B. IBM BLU einzuführen?

Basierend auf der zum Einsatz kommenden Backend-Technologie sind die eigent-

liche Modellierung und das Data Warehouse-Management zu untersuchen. In

Anlehnung an die LSA-Grundsätze (Layered scalable architecture) ist ein applika-

tionsspezifischer Data Mart, mit einer für die arcplan-Anwendung optimierten

Dimensionierung, Granularität (ggf. Einsatz von Aggregaten), Partitionierung und

auch regelmäßigen Komprimierung, zu empfehlen. Abfragen können durch den

Einsatz virtueller Sichten (MultiProvider) parallelisiert werden. Auch technische

Aspekte, wie die Frage nach korrekt gesetzten Indizes, sind zu untersuchen.

Insbesondere für initiale Aufrufe einzelner Berichte ist der standardmäßig abge-

fragte Datenraum in aller Regel bekannt. Dieser sollte so performant wie möglich

verfügbar sein, d.h. unnötige Aggregationen sind zu vermeiden.

Neben dem Einsatz der klassischen SAP BW Caching-Mechanismen sind weitere

Konzepte zur Vorberechnung von Werten (Predictive Caching), gegebenenfalls

hinsichtlich ihrer Anwendbarkeit, zu untersuchen.

Ausgangspunkt einer techni-

schen Analyse zur Perfor-

mancesteigerung ist immer

der Daten Layer.

Für arcplan sind optimierte

Data Marts zu empfehlen.

Seite 9



3.2.2 Business Layer Aufbauend auf der Analyse des Daten Layers werden nun alle Detailaspekte im

Business Layer untersucht und ausgewertet. Dabei sind im Wesentlichen der

Query-Aufbau sowie Variablen und Filter interessant. Insbesondere die Art und

Weise der Filterung von Query-Ergebnissen hat einen massiven Einfluss auf die

Abfrage-Performance. Pauschal kann gesagt werden, dass Filterungen immer

über Variablen erfolgen sollen, niemals über Einschränkungen im Sinne eines

WHERE-Statements.

3.2.3 Frontend Layer Im dritten Schritt wird nun der Frontend Layer, also die eigentliche arcplan-

Anwendung im Detail beleuchtet.

Datenabfragen können, durch Verbindungen zwischen einzelnen Objekten, in

Form von arcplan-typischen Verbindungspfeilen, schnell und einfach erstellt

werden. Die Technologie arcplan erstellt im Hintergrund entsprechende MDX2-

Statements. Die so automatisiert generierten Statements liefern das inhaltlich

korrekte Ergebnis, sind allerdings nicht immer die performanteste Möglichkeit

der Datenabfrage, da häufig ein gewisser „Overhead“ generiert wird. Dieser, der

Usability geschuldete, „Overhead“ der MDX-Befehle kann durchaus Perfor-

manceverluste bedingen. Bei der manuellen Erstellung von MDX-Statements

ohne die Verwendung von Verbindungspfeilen fällt dieser Overhead weg. Voraus-

setzung für die manuelle Erstellung von MDX-Statements ist die intensivere

Auseinandersetzung mit dem Datenmodell und der Struktur der abzufragenden

Daten. Dies resultiert häufig auch in einer in Summe geringeren Anzahl an Daten-

abfragen. (Eine Reduktion von sechs auf eine Datenabfrage sind keine Seltenheit

im Rahmen des Performance Optimization Packages.) Dies ist insofern eine

wesentliche Stellschraube zur Performanceverbesserung, da die entsprechenden

Abfragen nicht parallel, sondern sequentiell ausgeführt werden.

Anmerkung:

Braincourt bietet im Rahmen der Schulungsorganisation BrainAcademy MDX-

Schulungen an. Neben einem sehr interessanten Kosten-Nutzen-Verhältnis ist die

Individualität der Schulungen durch die größtmögliche Berücksichtigung von

Kundenspezifika ein zusätzlicher Vorteil, den die BrainAcademy bietet. Siehe dazu

auch den folgenden Artikel zur BrainAcademy.

2 MDX (Multidimensional Expressions) ist die Abfragesprache für mehrdimensionale Daten, wie sie üblicher-weise in Cubes vorliegen. Ursprünglich von Microsoft entwickelt, hat MDX sich zum Standard für OLAP-Daten-banken entwickelt.

Verbindungspfeile unterstüt-

zen zwar die Anwendungs-

freundlichkeit (für den Ent-

wickler), aus Performance-

Gesichtspunkten sollte deren

Einsatz jedoch wohlüberlegt

sein.

Die MDX-Syntax ist nicht allen

arcplan-Entwicklern bekannt.

Eine Grundlagenschulung

kann das notwendige Wissen

vermitteln.

Die technische Gestaltung von

BEx-Queries hat einen signifi-

kanten Einfluss auf die Perfor-

mance einer arcplan-Anwen-

dung.

http://www.braincourt.com/fileadmin/user_upload/Downloads/N_Artikel/BrainAcademy.pdf

Seite 10



Der nächste Betrachtungsaspekt im Frontend Layer sollte der Zeitpunkt der Aus-

führung von Datenabfragen sein. Performance- bzw. Akzeptanzprobleme treten

in arcplan-Anwendungen auf, wenn nach jeder Filterumstellung sofort der

gesamte Bericht aktualisiert wird, bevor die nächste Filtereinstellung vorgenom-

men werden kann. Dies führt schnell zu erheblichen Verzögerungen bei der

Erstellung kombinierter Einschränkungen. Standardmäßig führt arcplan alle

definierten Abfragen aus, die im Fokus liegen bzw. die den Fokus erhalten. Dieses

Verhalten führt dazu, dass immer von aktualisierten Daten ausgegangen werden

kann. In vielen Fällen ist dies aber im Kontext des „Programmablaufes“ nicht

zwingend notwendig. Eine aktive Steuerung, wann welche Abfragen ausgeführt

werden sollen, ist zu empfehlen. arcplan bietet hierfür die Einstellung „automa-

tisch aktualisieren“, welche für jedes Datenbankobjekt definiert werden kann, an.

Kritisch zu hinterfragen, ist auch stets die Größe von Abfragemengen. Die Abfra-

gemenge sollte generell auf ein Minimum, das heißt auf den für den jeweiligen

Bericht tatsächlich benötigten Datenraum, reduziert werden.

Unter der Überschrift „Bewegungs- versus Stammdaten“ ist im Wesentlichen zu

untersuchen, an welchen Stellen Filterobjekte auf den Stammdaten oder auf den

Bewegungsdaten basieren sollen. Neben dem entsprechenden Zugriff auf die

originären Stamm- oder Bewegungsdaten sind auch Kombinationsmöglichkeiten,

wie z.B. die performanceoptimierte Speicherung gültiger Kombinationsmöglich-

keiten in einem DSO (DataStore-Objekt) denkbar.

Ein weiterer Aspekt für die Performance des Erstaufrufes eines arcplan Berichtes

ist die physische Dateigröße. Eine Verkleinerung der Dateigröße (durch Leeren

großer Datenbankobjekte) beschleunigt den entsprechenden Aufruf.

Neben der Datenabfrage über MDX-Statements bietet arcplan die Möglichkeit

über RFC-Bausteine (Remote Function Calls) mit dem BW-Backend zu inter-

agieren. Die enormen Möglichkeiten dieser Schnittstelle werden in aller Regel

völlig unterschätzt bzw. sind den arcplan-Entwicklern nicht bekannt. Zur mög-

lichst performanten Gestaltung einer arcplan-Anwendung sollte der Einsatz von

RFCs immer geprüft werden. Insbesondere für die Befüllung von Filterobjekten

ist eine erheblich bessere Performance beim Einsatz von RFCs zu erreichen. Mit

RFCs lassen sich auch die eingangs erwähnten Funktionalitäten realisieren,

welche häufig unnötigerweise über eine SQL-Datenbank abgebildet werden.

3.2.4 Consumer Layer Auch der Consumer Layer enthält im Detail einige Stellschrauben zur

Performancesteigerung. Dazu gehören unter anderem der Netzdurchsatz, die

arcplan Server Settings und etwaige Firewalls.

So können beim Netzdurchsatz die Antwortzeiten analysiert, bei den arcplan

Server Settings unter anderem die Cache Settings (Shared Query-Cache)

überprüft und die Firewall auf Overheadtimes hin untersucht werden.

Das gezielte Deaktivieren der

automatischen Aktualisierung

einzelner Datenbankobjekte in

arcplan verbessert die Anwen-

derzufriedenheit.

RFCs werden in den meisten

arcplan-Projekten unter-

schätzt.

Auch im Consumer Layer gibt

es Analyseaspekte, wie z.B. die

arcplan Server Settings.

Seite 11



4 Vorgehen im Performance Optimization Package Das Performance Optimization Package stellt den Best Practice-Ansatz von

Braincourt zur standardisierten Performance-Optimierung von arcplan-Anwen-

dungen in SAP BW-Umgebungen dar. Neben den technischen Aspekten der vier

Layer wird auch auf den organisatorischen Aspekt der Zusammenarbeit zwischen

Fachbereich, IT-Abteilung und hier insbesondere zwischen arcplan- und SAP BW-

Entwicklern eingegangen.

Das grobe Vorgehen ist in der nachfolgenden Abbildung visualisiert:

Abbildung 4: Grobes Vorgehen - Performance Optimization Package

Der Projektstart erfolgt mit einem gemeinsamen KickOff, bei dem die im Fokus

der Performance-Optimierung stehenden Berichte und konkrete Anwendungs-

fälle bzw. Navigationsschritte definiert werden. Ziel des Performance

Optimization Packages ist es, diese Berichte prototypisch zu optimieren und den

Weg für eine umfassende Performance-Optimierung aller im Einsatz befindlicher

arcplan-Anwendungen aufzuzeigen. Einen wesentlichen Aspekt des KickOffs

stellt die Involvierung aller beteiligten Parteien, d.h. insbesondere der arcplan-

und SAP BW-Entwickler dar. Es erfolgt eine erste gemeinsame Sichtung der

identifizierten Berichte und es werden die wesentlichen Knackpunkte mit den

Endanwendern besprochen.

Anschließend erfolgt die IST-Aufnahme, d.h. die explizite Messung der IST-Ant-

wortzeiten. Hierzu gibt es verschiedene Möglichkeiten. Die fundierte und von

Braincourt präferierte Möglichkeit ist die Messung der einzelnen Antwortzeiten

auf Backend- und Frontendebene durch das Auslesen entsprechender techni-

scher Protokolle. Üblicherweise werden dazu in den verschiedenen Layern 10 bis

20 Messpunkte definiert.

Der Best Practice-Ansatz von

Braincourt und das standardi-

sierte Vorgehensmodell

führen zum Erfolg – garantiert

und zum Festpreis.

Eine durchgehende Begleitung

des Projektes durch die rele-

vanten arcplan- und SAP BW-

Entwickler ist zu empfehlen.

Seite 12



Ist die Ausgangs-Performance bekannt, werden die in Kapitel 3 beschriebenen

Ansatzpunkte (Zusammenarbeitsmodell, Daten-, Business-, Frontend- und

Consumer Layer) analysiert. Wichtig hierbei ist eine idealerweise kontinuierliche

Anwesenheit der relevanten arcplan- und SAP BW-Entwickler. Durch diese Vor-

gehensweise kann bereits während der Durchführung des Performance

Optimization Packages ein besseres Verständnis der jeweiligen technischen Be-

sonderheiten aufgebaut werden. Etwaigen politischen Hintergründen der betei-

ligten Personen wird in dieser Phase mit der notwendigen Sensibilität begegnet.

Auf Basis unserer umfangreichen Erfahrungen im relevanten Umfeld, findet im

Rahmen des Performance Optimization Packages eine grobe Einschätzung des

Kosten-Nutzen-Verhältnisses der möglichen Maßnahmen statt, so dass im An-

schluss an die Analyse eine Priorisierung der konkret durchzuführenden Maßnah-

men vorgenommen werden kann. Die Einführung neuerer Technologien wie SAP

HANA oder IBM BLU ist selbstverständlich nicht mit der Umstellung der Datenab-

fragen auf manuell generierte MDX-Statements zu vergleichen.

Die so identifizierten „sinnvollen“ Maßnahmen werden in Form eines Grob-

konzeptes beschrieben. Auf dieser Basis können die Rollenverteilung definiert

und die notwendigen Anpassungen am Backend, den Queries und dem Frontend

durchgeführt werden.

Ein Schlüssel zum Erfolg ist die integrative Zusammenarbeit zwischen Kunde,

Dienstleister, arcplan-Entwicklern und SAP-Abteilung. Üblicherweise entwickelt

sich durch geeignete Maßnahmen im Rahmen des Performance Optimization

Packages ein konstruktives Miteinander, bei dem alle Parteien voneinander

profitieren.

Abschließend wird die Messung der Performance analog zur IST-Aufnahme

durchgeführt und die Ergebnisse werden entsprechend verglichen. Nachfolgend

ein reales Beispiel:

Abbildung 5: Antwortzeiten (vorher/nachher/Steigerung [s]

Strukturierte Analyse der fünf

Ansatzpunkte im Rahmen des

Performance Optimization

Packages.

Seite 13



Die im Rahmen des Performance Optimization Packages, gewonnenen Erkennt-

nisse und das neue Know-how können in der Folge für die Optimierung weiterer

Bestandteile der arcplan-Anwendungen analog angewendet werden. Durch eine

Dokumentation und den projektbegleitenden Know-how Transfer, sind unsere

Kunden meist in der Lage, die weiteren Optimierungen eigenständig durch-

zuführen.

Braincourt hat in den letzten 15 Jahren erfolgreich etliche Performance-

Optimierungen von verschiedensten arcplan-Anwendungen durchgeführt. Die

gewonnenen Erfahrungen sowie das relevante technologische, methodische und

organisatorische Know-how haben wir im Performance Optimization Package

gebündelt. Dieses Package garantiert Ihnen, unter anderem durch das standardi-

sierte Vorgehen, die erfolgreiche Performance-Optimierung von auf SAP BW

basierenden arcplan-Anwendungen zum Festpreis! Performanceverbesserungen

um mehr als 90% sind keine Seltenheit, sondern der Normalfall.

Der vorliegende Artikel kann die einzelnen Aspekte des Performance

Optimization Packages, welche zu einem Quick-Win führen, lediglich grob dar-

stellen. Sollten Sie Interesse an einer Vertiefung des Themas haben, freuen wir

uns über Ihre Kontaktaufnahme.

5 Ihre Ansprechpartner

Marc Schlipphak Senior Manager Braincourt GmbH Fasanenweg 11 70771 Leinfelden-Echterdingen [email protected] Telefon: +49 711 75 85 80 -53

Manuel Schlereth Manager Braincourt GmbH Fasanenweg 11 70771 Leinfelden-Echterdingen [email protected] Telefon: +49 711 75 85 80 -0

Kontaktieren Sie uns, um

mehr Details zu erfahren.

mailto:[email protected]

mailto:[email protected]

Documents

Standardisierte Performance-Optimierung von arcplan ... · PDF fileSAP BW-Entwickler wissen, wohin der Fachbereich „fahren“ möchte, der arcplan-Entwickler sollte verstehen, was