Performance in CCH Tagetik: Die richtige Architektur entscheidet

In einer Zeit, in der Unternehmen mit exponentiell wachsenden Datenmengen konfrontiert sind und gleichzeitig agile Entscheidungsprozesse erfordern, entwickelt sich die Performance von Planungssystemen wie CCH Tagetik zum strategischen Wettbewerbsfaktor. Während viele Anwender bei PerformanceProblemen reflexartig nach technischen Engpässen oder Infrastrukturdefiziten suchen, offenbart die Praxis eine grundlegendere Wahrheit: Die wahren Hebel für Effizienz liegen in der intelligenten Systemarchitektur und der durchdachten Strukturierung der Anwendungslogik.

Hier kommt das KISS-Prinzip ("Keep it simple, stupid!") ins Spiel. Eine Leitlinie, die in der Softwareentwicklung seit Jahrzehnten gilt und auch für CCH Tagetik-Implementierungen entscheidend ist. Allzu oft führen überbordende Fachbereichsanforderungen mit unzähligen Sonderfällen und Ausnahmeregelungen zu einer komplexen, schwerfälligen Systemlandschaft, die nicht nur die Performance beeinträchtigt, sondern auch die Wartbarkeit und Nutzerakzeptanz gefährdet. Die Kunst besteht darin, zwischen berechtigten Geschäftsanforderungen und unnötiger Funktionsüberfrachtung zu unterscheiden, um dort, wo möglich, auf schlanke, effiziente Lösungen zu setzen.

Verschachtelte Logiken als unsichtbarer Bremsklotz 

Ein Report in CCH Tagetik ist weit mehr als nur ein Ergebnisbildschirm: Er spiegelt die gesamte Systemlogik wider. Wenn ein Report langsam reagiert, liegt dies selten an den technischen Grenzen des Systems, sondern daran, dass er so aufgebaut ist, dass CCH Tagetik unnötige Umwege gehen muss. Einer der häufigsten Performance-Hemmnisse sind verschachtelte Logiken. Formeln, die ineinandergreifen, Abfragen, die mehrfach ausgeführt werden, und Berechnungen, die sich gegenseitig bedingen, mögen auf den ersten Blick kompakt wirken. Im Hintergrund erzeugen sie jedoch eine Kaskade von Rechenschritten, die das System zwingen, tiefer zu rechnen, häufiger zu prüfen und mehr Speicher zu nutzen. Klare, entkoppelte Berechnungen beschleunigen Berichte dagegen sofort, da CCH Tagetik auf diese Weise ohne Umwege zum gewünschten Ergebnis gelangt. 

Große Matrizen nicht immer ein Vorteil 

Eng verbunden mit der Logik ist die Struktur der Matrizen, die eine multidimensionale Darstellung von Daten in Zeilen und Spalten ermöglichen. Große, allumfassende Matrizen wirken zwar effizient, da alle relevanten Daten an einem Ort konzentriert sind, erweisen sich in der Praxis jedoch oft als schwerfällig. Jede Aktualisierung zwingt das System dazu, eine große Menge an Dimensionen, Aggregationen und Berechnungen gleichzeitig zu verarbeiten. Kleinere Matrizen laden schneller, lassen sich besser kontrollieren und reduzieren die Rechenlast spürbar. Darüber hinaus können mehrere kleinere, thematisch abgegrenzte Matrizen diese Last verteilen und sorgen dafür, dass Berichte deutlich reaktionsschneller werden. Ein weiterer Fokuspunkt können die Berichte selbst sein. Statt einem Report mit fünf Sheets, von denen nur eines regelmäßig genutzt wird, können fünf separate, schlanke Reports oft die bessere Lösung sein.

Reporting Engine als technische Grundlage für effiziente Datenverarbeitung 

Ein zentraler, aber oft übersehener Hebel für die Performance ist die Wahl der richtigen Reporting Engine. Diese bestimmt, wie Daten abgefragt, transformiert und verarbeitet werden und damit direkt, wie schnell und skalierbar Berichte reagieren. CCH Tagetik bietet zwei grundlegend verschiedene Engines an: 

Die Standard Engine führt komplexe SQL-Abfragen direkt in der Datenbank aus. Alle Transformationen, wie On-the-fly-Konvertierungen, Segmente oder zeitabhängige Berechnungen, werden dabei auf Datenbankebene verarbeitet. Diese Engine eignet sich besonders, wenn nur minimale Transformationen auf den zu extrahierenden Datenblock angewendet werden müssen, wenn eine SAP HANA-Datenbank genutzt wird oder wenn eine große Anzahl von Filtern zum Einsatz kommt. Ihr Vorteil liegt in der direkten Verarbeitung innerhalb der Datenbank, was bei einfachen, filterlastigen Abfragen oft die effizientere Lösung darstellt. 

Die In-Memory Engine verlagert die Rechenlast dagegen vom Datenbankserver auf den Anwendungsserver und verarbeitet die Daten im Arbeitsspeicher. Dies führt zu einer deutlich höheren Skalierbarkeit, da die Engine Parallelitätsmechanismen nutzt, die zusätzliche Concurrency-Einstellungen überflüssig machen. Besonders bei komplexen Berichten – etwa mit Segmenten, Wechselkursen oder zeitabhängigen Berechnungen, kann die In-Memory Engine die Laufzeit spürbar reduzieren. Beim Wechsel zwischen den Engines werden die Concurrency-Einstellungen zurückgesetzt. Während die Standard Engine die definierten Parallelitätseinstellungen beibehält, setzt die In-Memory Engine den Grad der Nebenläufigkeit standardmäßig auf eins, da ihre Architektur bereits für effiziente Parallelverarbeitung optimiert ist. Für den Einsatz der In-Memory Engine sollten zudem die Blockgröße (Anzahl der Zeilen pro Block), die Größe des Threadpools für das Laden der Daten sowie die Größe des Threadpools für die Datenverarbeitung an die Anforderungen angepasst werden. 

Die bewusste Auswahl der passenden Reporting Engine kann die Performance von Berichten und Formen entscheidend verbessern, besonders bei komplexen oder datenintensiven Szenarien. Hierbei gilt der einfache Ansatz: Ausprobieren. Man kann nichts zerstören.

Filter und Parametrisierung bieten zielgerichtete Datenverarbeitung 

Sobald die Logik, die Matrizen und die Reporting Engine optimiert sind, kommt es darauf an, die Datenverarbeitung gezielt zu steuern. Filter entscheiden maßgeblich darüber, ob CCH Tagetik effizient arbeitet oder sich durch unnötige Datenmengen kämpfen muss. Richtig eingesetzt, reduzieren sie die zu verarbeitenden Daten bereits zu Beginn des Prozesses und beschleunigen so den gesamten Report. Technisch ist dabei zu beachten: Wenn nur eine Matrix im Report vorhanden ist, sollte diese direkt gefiltert werden, um den Form-Filter zu umgehen. Bei mehreren Matrizen empfiehlt sich dagegen eine klare Reihenfolge: Zuerst der Form-Filter, dann der Matrix-Filter und zuletzt Row-/Column-Filter. Diese Abfolge stellt sicher, dass CCH Tagetik die Daten schrittweise eingrenzt und nur das verarbeitet, was tatsächlich benötigt wird. 

Werden Filter falsch platziert, etwa erst auf Report-Ebene statt direkt an der Matrix, entfalten sie ihre Wirkung zu spät. In diesem Fall rechnet das System zunächst mehr, als tatsächlich erforderlich wäre, und verwirft die überflüssigen Ergebnisse anschließend wieder. Die Parametrisierung verstärkt diesen Effekt: Berichte, die sauber parametrisiert sind, geben CCH Tagetik von Anfang an klare Vorgaben. Parameter wie Zeitraum, Version, Gesellschaft oder Szenario stehen fest, bevor der erste Rechenschritt erfolgt. CCH Tagetik kann so zielgerichtet arbeiten, ohne unnötige Abfragen oder wiederholte Evaluierungen durchführen zu müssen.

Outlier Content und Stammdatenmodell sichern langfristige Performance

Auch die bestoptimierten Reports verlieren mit der Zeit an Performance, wenn sie nicht regelmäßig gewartet werden. Mit der Zeit sammeln sich Inhalte an, die nicht mehr benötigt werden: alte Berechnungen, Hilfselemente aus früheren Versionen oder Logiken, die längst durch andere ersetzt wurden. Dieser sogenannte Outlier Content verlangsamt Berichte schleichend, ohne dass dies sofort auffällt. Regelmäßiges Aufräumen hält Reports schlank und sorgt dafür, dass CCH Tagetik bei jedem Refresh nicht unnötigen Ballast mitführt. Ebenso wichtig ist die Pflege des Stamm- und Bewegungsdatenmodells. Wenn Dimensionselemente und Berechnungslogiken sauber gepflegt und eindeutig definiert sind, vermeidet dies doppelte Definitionen und redundante Inhalte sowie unnötige Datenpunkte und eine überlastete Datenbank. Reports werden klarer strukturiert, stabiler und schneller, da das System eindeutige Zugriffspunkte hat.

Datenbankoptimierung durch Partitionierung und Indizes 

Ein ergänzender Fokus liegt inzwischen auf dem Analytical Information Hub, welcher immer weiter in den Fokus rückt. Vor allem mit Blick auf Datenmanagement trägt dieser viel Optimierungspotential in sich. Für hochfrequentierte Tabellen (z. B. in der Salesplanung) sollten Indizes eingerichtet werden. Wenn Ihre CCH Tagetik-Lösung mit großen Datenmengen (z. B. IST-Daten auf Belegebene) arbeitet, hilft eine Aufteilung der Datenbanktabellen in kleinere Abschnitte durch Indexieren. Statt einer riesigen Tabelle entstehen mehrere überschaubare Tabellen, was den Zugriff beschleunigt und das System entlastet. Ihre Berichte werden schneller, und die Performance bleibt auch bei wachsenden Datenmengen stabil. Eine einfache, aber effektive Maßnahme für mehr Effizienz.