Industrial group (DAX) · Industry / Manufacturing

How an independent assessment brought clarity to a grown SAP BW/HANA landscape

Independent assessmentSAP BW / HANAArchitecture reviewRoadmap

An independent assessment is at its most valuable when it doesn't have to please anyone - and can still be pinned to hard facts.

Starting point

A DAX industrial group runs a multi-terabyte analytics landscape on SAP BW (the data warehouse) and the in-memory database HANA for its supply-chain management, operated by an external service provider for years. The business side reported growing doubts about stability and steerability: slower reports, hard-to-trace behaviour in planning, and hardly anyone left in-house who fully understood the architecture that had grown over the years.

We were given the role of the independent assessor - tasked with evaluating the state of the landscape in a structured, fact-based way rather than glossing over it. Three parties, three interests: the business side, which wanted answers; the service provider, which defended its work; and a neutral party in between, attached to neither the system nor the contract.

Approach

The landscape was examined across eight dimensions - from system versions through data loading, enrichment, master data, storage and modelling to planning, frontend and authorisations. Each dimension was assessed by the same pattern: finding, recommendation, effort and expected impact. Deliberately kept separate, so it becomes clear what is urgent and what is not, and what takes effort and what does not.

Assessment at a glance

Of eight assessed dimensions, one had already been resolved in the course of the assessment, five call for monitoring and two for immediate action. The table condenses numerous individual findings into eight dimensions and names only the central risk per dimension.

DimensionStatusEffortKey risk
System versions & releasesAction neededmediumReleases several versions behind - upgrade scheduled short-term.
Data loading & integrationMonitorlong-termOperational, but the existing integration pipeline is strategically at its end.
Data enrichmentMonitormedium - highNo monitoring of the enrichment logic; errors surface late, undo is costly.
Master data & process chainsMonitormediumMaster-data maintenance driven heavily by process chains (scheduled load runs) and manual input - data quality hinges on a few points.
HANA setup & storageResolvedlowStorage out of control, QA blocked - remediated during the assessment.
Modelling (HANA & BW)MonitormediumGrown over years, an overall view is missing.
Planning & frontendMonitormediumPlanning logic hard to trace, frontend alternatives to be evaluated.
AuthorisationsAction neededmediumAuthorisation concept to be tightened short-term.

Two findings in detail

The assessment covered far more individual points than can be shown here. We single out two as examples - one already resolved, one still open:

HANA setup & storageResolved
Finding
The in-memory database occupied around 4.2 TB on disk against only about 1.2 TB of used memory - and the trend kept rising, so disk capacity had to be added. The core cause was a single table of around 2.5 TB holding intermediate load data that was never cleaned up. The heaviest operational consequence: copying production into the QA environment (the test system) was no longer possible - tests ran without a reliable image of production.
Recommendation
Clean up the intermediate layer and establish a regular reclaim (the scheduled release of occupied storage), timed outside business hours to keep system load low.
Effort
Low. No effort on the business side; the operations provider identifies obsolete data and tables, the infrastructure partner then releases the storage.
Impact
Storage requirement reduced from around 4.2 to about 1 TB. Shorter backup times, noticeably higher stability - and a restorable QA environment.
Data enrichment & traceabilityMonitor
Finding
After loading, the data is enriched in HANA through many cascaded stored procedures (automated database routines), driven by manually maintained values from a business enrichment tool. Only a few authorised experts may change these values; the changes are logged. What is missing is overarching monitoring of the enrichment itself: with faulty input or procedures running incorrectly, errors are not caught early - and rolling them back would be complex and costly.
Recommendation
Introduce lightweight monitoring - log runtime and the number of objects processed per procedure in a separate table (a few rows per procedure). The evaluation creates transparency over processing and performance and makes bottlenecks visible and optimisable.
Effort
Medium to high. Depending on whether the existing processing supports such monitoring or needs to be adapted for it.
Impact
Data quality today hinges heavily on manual interaction - a permanent source of error. The tight authorisation model limits the risk but does not remove it. Without monitoring, a blind spot remains exactly where data quality is created.

Recommendation: a three-horizon approach

Short-term. Update system versions (upgrade) and tighten the authorisation concept - both with immediate impact on stability and security.

Medium-term. Rework the planning logic, evaluate frontend alternatives and introduce monitoring of the enrichment.

Long-term. Evolve the analytics layer towards a modern data platform (data-lake integration) and replace the existing data-integration tooling.

In the end there was no verdict on people or providers, but a solid basis for decisions: what needs fixing immediately, what to keep monitoring and where the architecture should be fundamentally rethought. That is exactly the job of an independent assessment.

We offer this assessment as a standalone service - the independent assessment as a neutral status assessment for SAP, data and AI landscapes.

A similar project?

We will talk through your starting point - and a realistic path to the result.

Book an intro call
← All success stories