How SAP Analytics Cloud Adapts to Different SAP Landscapes: Three ACBaltica Case Studies

Pavel Ramanouski, Head of SAP BI and EPM practice at ACBaltica

SAP Analytics Cloud (SAC) can be used in different ways, depending on the business situation. In some cases, it serves as a central planning environment that brings together financial, operational, and personnel data. In other cases, it helps people plan investments and create models of what could happen. Sometimes, it works like a control panel, showing the current status of the whole supply chain in real time.

Three ACBaltica projects show how one platform can be used in different ways to meet different needs and even architectures. It can be used at operational, strategic, and network levels to solve different business problems. Let's take a look under the hood.

Case 1. IT company: Bringing project planning together

Architecture: SAC + SAP S/4HANA Public Cloud

Overview: The first story comes from a fast-growing enterprise software developer. The company was growing quickly, and each department had its own planning process. The finance department tracked budgets, project managers managed costs separately, and the HR department maintained staffing data independently. This fragmentation made it difficult to understand the connections between projects, resources, and profitability. Because planning was spread across many layers and there was no single platform to unify it, resource allocation became difficult, and period-end closures took longer, which delayed access to data and slowed decision-making.

Challenge: Before switching to SAP, the company used Oracle NetSuite for accounting, which is a system designed for medium-sized businesses. However, as the organization grew, NetSuite began to limit further development. Meanwhile, different departments relied on their own tools and processes, making planning even more fragmented.

Solution: The company decided to transition to SAP S/4HANA Public Cloud as the central accounting platform and use SAP Analytics Cloud for planning and reporting. From an architectural perspective, this is a classic and efficient setup: S/4HANA serves as the transactional core, while SAC provides a ready-to-activate planning layer with standard content that can be quickly adapted to the business, enabling standard reports, planning templates, and forecasts that could be extended where needed. 

The goal was to connect operational and financial planning so that the company could see the profitability of each unit and allocate resources accordingly.

In this setup, SAC became the core of managerial analytics, a shared environment where departments could speak the same financial language.

Case 2. Healthcare manufacturer: Making CAPEX planning digital

Architecture: SAC + SAP BW on HANA + ERP 

Overview: The second case comes from a healthcare manufacturer with a large and complex investment portfolio. While the company already used SAP, their planning landscape needed unification. Strategic project evaluations were prepared in Excel. Each business unit developed its own business cases, calculated expected returns, and submitted spreadsheets for approval. However, financial planning was handled separately in SAP Analytics Cloud, with no direct connection to strategic inputs.

Challenge: The business case creation and financial planning processes, which were connected, existed in separate systems. This resulted in manual work and slower decision-making, as well as the usual risks of duplicate data and inconsistencies.

Solution: We redesigned the process to make SAC the central location for business cases, portfolio overviews, and financial simulations. We moved the business case creation process into SAC and integrated data from BW and ERP into a single planning model. This enables managers to track all investment initiatives, compare scenarios, and understand the financial impact, all without having to switch between tools.

The value lies in the structure. Two previously disconnected processes became a single, traceable planning cycle. Manual data entry was eliminated, errors were reduced, and decision-making became faster and more transparent.

In this scenario, SAC acted as a strategic planning layer on top of the existing BW and ERP systems.

Case 3. Pharmaceutical distributor: Seeing the supply chain clearly

Architecture: SAC + ECC (live data connection)

Overview: The third case is from the pharmaceutical distribution sector, which works with hundreds of suppliers. Each supplier expects the distributor to provide regular reporting on stock levels, sales volumes across channels, and other indicators.

Challenge: Before the project, the company used SAP ECC on HANA, the legacy version of SAP ERP. Reporting for suppliers was handled manually. Custom transactions in ECC generated extracts that an employee exported into Excel and emailed to each supplier individually. This was a time-consuming process repeated monthly for hundreds of partners.

Solution: The goal was to automate this flow and give suppliers access to up-to-date information whenever they needed it. We implemented a solution where relevant data from ECC is regularly loaded into SAP Analytics Cloud, transformed into intuitive dashboards, and published through secure access profiles. Suppliers can now log in and view stock and sales information for their products near-real-time, without waiting for monthly email reports. SAC provided visual dashboards, easy navigation, and a clean interface that suppliers could understand without training. The result was a reporting portal that extended the client’s SAP landscape outward.

Here, SAC functioned as an external-facing analytics portal, modernizing a legacy ECC landscape without requiring a migration to S/4HANA and dramatically reducing manual effort in supplier communication.

What do these cases have in common?

Looking at these three projects, it’s clear that all the companies faced a similar high-level challenge: data scattered across systems, slow reporting, and limited visibility for decision-making.

But the way they solved it was very different, and that’s what’s interesting.

• In the IT company, SAC helped connect project, financial, and staffing data into a single, unified model. Managers could finally see how operational plans aligned with financial goals.

• In the healthcare manufacturer, SAC was used for scenario-based CAPEX modeling and dependency analysis, helping the team prioritize investments and anticipate the effects of different decisions.

• In the pharmaceutical distributor, SAC provided live dashboards and self-service reports that made sales, inventory, and logistics visible in real time.

The common thread is that SAC didn’t look or function the same in every case. Rather, each implementation adapted to the company’s existing architecture, workflows, and goals.

How to choose the right approach for implementing SAC in your business

Looking at the three cases, one thing becomes clear: there’s no one-size-fits-all implementation. Your approach should depend on your company’s systems, processes, and priorities.

Here are a few practical points to consider:

1. Understand your challenge first
   Identify where SAC can add value. Start with areas where quick wins are possible, such as connecting finance and operations, planning investments, or monitoring real-time operations, and expand from there.

2. Map your existing architecture
   Consider your ERP, data warehouses, and other systems. SAC can integrate with different landscapes, but the specifics will shape the solution.

3. Decide on the level of integration
   Do you need SAC as a central planning hub, a strategic layer, or an operational dashboard? The answer will guide your models and dashboards.

4. Think about adoption
   Who will use SAC day-to-day? What type of dashboards or reports will give them actionable insights? Tailor the solution to actual users.

5. Start small, scale fast
   Implement the first solution around a key business area, test the models, gather feedback, then expand to other processes or departments.

And remember that the best SAC implementation is the one that fits your business context and goals, not just the technology.

Conclusion

These three cases show that SAP Analytics Cloud does not require a specific type of SAP landscape to deliver value. Whether the foundation is S/4HANA Cloud, BW on HANA, or even ECC on HANA, SAC can take on the role that best fits the architecture and the business goals.

This flexibility is a big advantage for organizations that already use SAP. SAC can be introduced as a planning layer, a reporting environment, or a combined platform for integrated planning and analytics — without disrupting existing systems. It extends the value of the current SAP setup rather than replacing it, and it adapts to the level of maturity the company already has.

In practice, SAC can become the place where operational planning is unified, where strategic processes are connected, or where external partners receive transparent reporting. The architecture determines the shape of the solution, but the outcome is the same: faster insights, fewer manual steps, and a more connected planning landscape.

SAC fits naturally into SAP-based environments. As these case studies demonstrate, its effectiveness is not dependent on the industry, but on the architecture and the tasks it is designed to perform.