Creating Value with SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver

Creating value with SAP® BusinessObjects™ Planning and
Consolidation, version for SAP NetWeaver®

Why organizations should consider SAP BusinessObjects Planning and Consolidation, version
for SAP NetWeaver, for new planning, budgeting, forecasting or consolidation projects

BY DAVID DIXON, VP RESEARCH AND ADVISORY AT BUSINESS & DECISION

Creating value with SAP® BusinessObjects™ Planning
and Consolidation, version for SAP NetWeaver®

Contents
1. Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2. The Case For SAP BusinessObjects Planning And Consolidation, Version For SAP NetWeaver . . . . . . 2
1. Invention Born Out Of Necessity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Mandate For Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Business Imperative For Agility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Managing Innovation And IT Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3. Creating Value With The Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Following A Roadmap Framework For Delivering Enterprise Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Leveraging The Platform – Data – Process Approach To Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Making Platform Integration Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Why SAP NetWeaver BW Is Inseparable From SAP ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Assessing The Oracle Hyperion Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
3. Assessing The Hyperion Essbase OLAP Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Assessing The SAP NetWeaver BW OLAP Engine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. How The Application Simplifies Database Complexities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Assessing How The Application Exploits Its Own Platform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. How To Leverage The SAP BusinessObjects BI Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. SAP NetWeaver BW BPS And SAP NetWeaver BW IP Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3. Making Data Integration Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Making Process Integration Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5. About The Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

7. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1. OLAP Explanation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

© 2010 BUSINESS & DECISION


1. Executive Summary
The SAP® BusinessObjects™ Planning and Consolidation application, version for the SAP NetWeaver® technology
platform, enables autonomy for both the business user and the finance administrator through a combination of benefits:
the familiarity of Microsoft Excel, the enterprise scalability of SAP and the enhanced analysis and business process
support of the application itself. Born out of market demand for better decision-making applications that reconcile both
business and IT needs, SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver, combines multiple
technologies. Integration with SAP BusinessObjects business intelligence, enterprise performance management and
governance, risk and compliance solutions further extends the reach of the application for financial planning, budgeting,
forecasting and consolidation, relieving customers from the burden of cross-platform integration themselves.

This merging of multiple applications creates opportunities and challenges, both of which demand effective
governance. Enterprises must redefine how business and IT can work both in conjunction and independently. However,
in order to redraw these lines of governance, business and IT need to be credible partners. While taking an enterprise-
wide approach may yield the most long-term value, rolling out solution capabilities in incremental phases rather than
as a “big bang” may prove equally as effective, and more efficient.

The driving market forces behind the need for an application like SAP BusinessObjects Planning and Consolidation,
version for SAP NetWeaver, are volatility and complexity. Enterprises demand agility supported by a stable core in order
to effectively manage change. Flexible applications atop an enterprise standard like SAP NetWeaver foster systems that
can evolve and adapt without significant disruption of the foundation. SAP BusinessObjects Planning and Consolidation,
version for SAP NetWeaver, leverages its platform strengths: tight integration with the SAP ERP application via its data
warehousing technology, the SAP NetWeaver Business Warehouse (SAP NetWeaver BW) component, and high-performance
query acceleration technology, SAP NetWeaver BW Accelerator software. Users can redefine financial planning, budgeting,
forecasting and consolidation models, processes, formats and conventions without compromising data quality and data
latency, which in turn delivers agility to the business without sacrificing quality and control. In addition, the application
offers the opportunity to further extract value out of the organizational capital invested in SAP applications.

SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver, offers three avenues of creating value:
platform, data and process. All interrelate, but the current customer and vendor focus is on exploiting the platform. Data
integration challenges, in turn, are a familiar area for data warehouse practitioners and closed-loop process integration
is an end-state vision. In addition, effectively leveraging the platform is necessary for the proper implementation and
function of downstream efforts.

When assessing SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver, there are numerous
platform considerations which require evaluation:

1. Why SAP NetWeaver BW is inseparable from SAP ERP if timely access to detailed and high-quality data is
needed.

2. What criteria to consider when evaluating SAP BusinessObjects Planning and Consolidation, version for SAP
NetWeaver, against competitor products like Oracle Hyperion.

3. How a product that uses On-Line Analytical Processing (OLAP) technology differs from the OLAP technology
itself. For example, there is a significant difference between Hyperion Planning (product based on OLAP) versus
Hyperion Essbase (the underlying OLAP technology).

4. What the OLAP technology options are and considerations vis-à-vis the end product. For instance, there is
a difference between SAP NetWeaver BW Accelerator and “out-of-the-box” OLAP functionality in terms of
product performance.

5. How the application shifts necessary design and skills away from the database and into the application itself in
order to improve IT productivity.

6. How the application maintains its database and file server independence and leverages SAP-standard data
management and system administration functionality, such as data load scheduling and application change control.

© 2010 BUSINESS & DECISION 1


7. How the platform extends beyond SAP NetWeaver into SAP BusinessObjects business intelligence solutions
for both single sign-on functionality and reporting and analysis tools. In addition to the native Excel tool in
SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver, users can employ Xcelsius, SAP ®

BusinessObjects Web Intelligence, Crystal Reports, SAP BusinessObjects Explorer and SAP BusinessObjects
® ®

Voyager software to analyze SAP BusinessObjects Planning and Consolidation data.

8. The migration considerations and paradigm differences between SAP BusinessObjects Planning and
Consolidation and the earlier SAP products for financial planning, budgeting and forecasting such as the
business planning and simulation functionality in the SAP Strategic Enterprise Management (SAP SEM®)
application (SAP SEM BPS) and SAP NetWeaver BW integrated planning functionality (SAP NetWeaver BW IP).

Integration considerations are similar to that of any new application, except that the nature of the work builds off an
analytic data mart. As a result, users must still define data mappings and address master data governance impacts. The
appropriate approach will be customer-specific, influenced by data warehousing strategy.

In terms of process integration, many SAP applications can be integrated into SAP BusinessObjects Planning
and Consolidation. However, the integration effort is non-trivial from both business and technology perspectives.
Leadership is needed and the Office of the CFO must act as a central advisor in defining effective management
processes for their organization.

Irrespective of the approach taken, SAP BusinessObjects Planning and Consolidation is a cornerstone application that
any SAP-based management and decision-making system must consider, if only for the simple reason that it enables two
central financial management capabilities: planning and consolidation. Not surprisingly, SAP BusinessObjects Planning
and Consolidation, version for SAP NetWeaver, has garnered a flurry of interest. With customers already live, and new
ones en route, the product demands close inspection.

2. The Case for SAP BusinessObjects Planning and Consolidation,
version for SAP NetWeaver
1. Invention Born Out of Necessity
SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver, is a market-driven innovation addressing
the need for a business-owned adaptive application on an enterprise-scalable platform. On the supply side, vendor
efforts and market consolidation have created new product hybrids. On the demand side, customer investments are
needed to exploit new value creation opportunities.

SAP took the first step to creating SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver, by
acquiring Outlooksoft (the corresponding application now known as SAP BusinessObjects Planning and Consolidation,
version for the Microsoft platform) in June of 2007. SAP’s second step involved acquiring Business Objects in February
2008. Subsequent development has resulted in an application that marries Outlooksoft, Business Objects and SAP
technologies. SAP first ported Outlooksoft to the SAP NetWeaver technical platform, and later integrated SAP
BusinessObjects Planning and Consolidation with other products in its portfolio, including products such as business
intelligence (BI), information management (IM), and governance, risk and compliance (GRC), as well as other enterprise
performance management (EPM) solutions.

Most large customer landscapes have yet to see such integration within their own complex environments, perhaps
because the technologies have not reached the enterprise-adoption tipping point. A more significant constraint is the
leadership necessary to integrate people, processes and policies. While large vendors take the lead on the technology
front to combine disparate BI tools, data warehouse (DW) infrastructure and performance management (PM) applications
into enterprise platforms, customers need new governance rules to extract value out of their expanded portfolio of
options. SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver, is a manifestation of this need for
greater flexibility and stability in changing times.



Porting a business user-centric application like Outlooksoft to the SAP NetWeaver technical platform brings new
economies of scale, as well as new governance rules, to this acquired innovation. In order to reap benefits of the
application, IT consolidation must occur. This consolidation requires centralized governance and a pooling of resources
to achieve synergies and avoid the cost of missed opportunities or hidden costs such as shadow IT expenditures.

2. The Mandate for Governance
The core challenge customers face in implementing the SAP BusinessObjects Planning and Consolidation, version for
SAP NetWeaver, is that the product itself creates a new paradigm within the customer’s organization. As a result, the
risk of pursuing the wrong business and use cases is higher. SAP BusinessObjects Planning and Consolidation, version
for SAP NetWeaver, represents a break from traditional SAP and Outlooksoft mindsets. For SAP practitioners, the
mindset to break is “IT control.” For Outlooksoft practitioners, the mindset to break is “business autonomy.” For both,
the trap to avoid is to look at the application too singularly. In other words, the integration into SAP NetWeaver, SAP
BusinessObjects solutions and Microsoft Office opens up hybrid solution scenarios, not necessarily competing ones.
From a control perspective, it opens up collaborative opportunities where business and IT work closer together as
opposed to separately.

Pragmatic “use-what-you’ve-got” and “do-more-with-less” principles require a synthesis of business user autonomy
and centralized IT control in order to spur co-creation, not wasteful competition. In order to create proper leverage,
enterprise IT assets must be standardized, integrated and shared. Furthermore, to expand resource capacity to build
and maintain those assets, the business users themselves can be put to work. SAP BusinessObjects Planning and
Consolidation, version for SAP NetWeaver, uses the familiarity of Microsoft Excel to effectively achieve these goals.

Generally, the business is willing to take ownership of its information assets in order to better service its own needs
and mitigate operational risk. IT needs to focus on higher-value core tasks like scalable architecture and design, data
stewardship and overall performance expectations and Service-Level Agreements (SLA). With new budgetary pressures,
IT runs the risk of being relegated to the “janitor” of IT systems while at the same time serving as short-order cooks
for sporadic business needs. In order to address swelling IT backlogs in resource-constrained times, the business itself
becomes an important resource, and IT must be a credible partner.

Not only is strong leadership and governance necessary to yield such collaborative cost efficiencies, but the technology
itself must be able to support business user self-service without sacrificing scalability. In this arena, a product that
combines the familiarity of Microsoft Excel (and BI tools such as Xcelsius, SAP BusinessObjects Web Intelligence, and
SAP BusinessObjects Explorer) with the enterprise scalability of SAP NetWeaver holds the most promise.

For customers that have created value by centralizing their SAP ERP investments, it is now time to apply the same
principles to BI and PM. But instead of automating business processes, the focus is now on managing those processes as
a management process itself. Furthermore, SAP BusinessObjects Planning and Consolidation can be implemented either
incrementally or as a single “big bang,” depending on the needs of the customer.

For example, the nation’s largest pet specialty retailer decided to limit the scope of their SAP BusinessObjects Planning
and Consolidation, version for SAP NetWeaver, implementation by focusing on profit-and-loss-based management
reporting which include hierarchical breakdowns, such as store and product categories, and variance analysis. Also,
by starting with corporate finance needs, the retailer can establish the foundation for future organizational and
technological phases.

In contrast, at a Fortune 500 consumer products company in the food industry, the implementation of the SAP
BusinessObjects Planning and Consolidation, version for SAP NetWeaver, is part of a major global initiative to
standardize planning processes. Improved reporting of planned versus actual profitability is of value in and of itself. The
SAP NetWeaver BW integration with SAP ERP facilitates timely financial reconciliation of the application. Increased data
volumes via SAP NetWeaver BW translate to functional reporting and analysis improvements. For instance, users can
easily drill down from product group to individual stock-keeping unit (SKU) details. The company can also break down
planned-versus-actual variances at a more detailed level such as price, volume and mix.

The consumer products company selected SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver,
as its standard and technology enabler in order to align with the vendor as well as its own SAP strategy. Over the long



term, the company expects IT consolidation and savings from migrating legacy applications, including Hyperion Financial
Management for financial consolidation and Oracle Financial Analyzer for planning. However, most of the expected
business value arises not from the technology itself, but from better governance and design of people and processes.

Other companies, such as a media conglomerate, find SAP BusinessObjects Planning and Consolidation, version for
SAP NetWeaver, an attractive option for a single process and platform to perform financial consolidation of both plan
and actual data. Such an implementation would enable this media conglomerate to retire, in phases, its legacy SAP
investments in SAP ERP and SAP NetWeaver BW for planning, financial consolidation and management reporting.

3. The Business Imperative for Agility
Recent Aberdeen research cites “the need to be flexible and dynamic to account for change” as the top pressure facing
best-in-class companies.1 A rapidly changing business climate only underlines the notion that a planning, budgeting and
forecasting application must be both customizable and extensible. Management applications must have user interfaces,
data models, workflows and business logic that users can rapidly adapt to changing business environments. Placing
management applications in the hands of the business and allowing self-service control via spreadsheet functionality on
flexible technical platforms, fosters corporate adaptability.

At the same time, the same Aberdeen study found best-in-class companies were increasingly seeking to “improve data
quality,” targeting it as a top strategic action. While SAP BusinessObjects Planning and Consolidation promotes more
adaptive financial planning, budgeting and forecasting, the version for SAP NetWeaver helps ensure improved data
quality via an established platform which integrates with its SAP sources.

One important aspect to both agility and data quality is data latency. Data latency, a familiar concept to most BI
practitioners, is pertinent to reporting requirements or SLAs. The old proverb “time is money” still succinctly sums up
the impact that data latency has on the business: the quality of decisions degrade with time.

The SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver, enables more integrated and
timely access to SAP ERP. For example, SAP NetWeaver BW has ERP-based changed data capture and remote access
techniques that enable scalable data freshness in near real-time. Meanwhile, separately licensed in-memory analytics
delivered by SAP NetWeaver BW Accelerator accelerate analysis, report delivery and ultimately, planning itself.

4. Managing Innovation and IT Complexity
While IT consolidation brings direct cost efficiencies by reducing vendor licenses and conserving infrastructure and
resources, it can also create indirect cost efficiencies by leveraging specialized skill sets and reducing the complexity
of the IT environment. Without centralized governance in place, individual departmental solutions and individual
spreadsheets proliferate, creating the IT equivalent of urban sprawl. End-user “quality of life” ultimately suffers, since
poorly-designed infrastructure results in data traffic delays and low-quality constructs.

Construction principles help address the challenges of IT complexity. In fact, Enterprise Architecture and data
warehousing practice is largely predicated on engineering disciplines2 But as IT investments grow and interrelate,
.
the metaphor of city planning becomes more appropriate than the more exact science of individual construction.
On the demand side, constituent requirements and needs are always changing. On the supply side, construction and
operations are always improving, as are industry practices and technological innovations. These moving targets
and fluctuating dynamics make road mapping an always-evolving exercise. Most customers undoubtedly have
spreadsheets scattered across the organization, not to mention shadow IT initiatives in dark corners. In addition,
typical landscapes also include homegrown legacy systems and non-SAP applications at the departmental and
enterprise levels.

In more specific SAP terms, many customers have also made heavy investments in other similar SAP applications
such as SAP SEM BPS, SAP NetWeaver BW BPS, and SAP NetWeaver BW IP. Even if such redundancies and tear-down
considerations did not exist, many customers still need to position SAP BusinessObjects Planning and Consolidation
within a portfolio of business applications and middleware, SAP and non-SAP alike. Such a mixed-bag portfolio almost
certainly contains applications such as SAP ERP, SAP Customer Relationship Management (SAP CRM) and SAP Supply
Chain Management (SAP SCM), and the SAP NetWeaver BW and SAP NetWeaver Portal components.



However, there is an effective approach to handling disparate applications beyond middleware. All of these applications
can be integrated via the same technical platform.

Just as mass-produced steel forever changed the city landscape by enabling the construction of skyscrapers and the
growth of cities, the SAP NetWeaver technical platform has been a backbone enabling large-footprint SAP applications
with the strength to run enterprise business processes. And just as the modern skyscraper forever changed the look of
cities, SAP ERP alone has forever changed enterprise IT landscapes.

The former Outlooksoft application takes advantage of the SAP NetWeaver technical platform as a new and separate
product, rebranded as SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver (It is important to
draw a distinction with the version for the Microsoft platform, which continues as a viable option for Microsoft shops.)
The version for SAP NetWeaver will continue to evolve as a separate product and exploit SAP NetWeaver strengths.
Already, the version for SAP NetWeaver has its own redesigned version of “Business Process Flows” for defining business
processes and integration with the SAP BusinessObjects Process Control application. In fact, the SAP roadmap for SAP
BusinessObjects Planning and Consolidation clearly shows the version for SAP NetWeaver will increasingly diverge
from the version for Microsoft from an infrastructure perspective. Meanwhile, the business user will see little difference
between the two; both possess the familiarity of the native Microsoft Excel-based interface and the enhanced analytical
functionality that SAP BusinessObjects Planning and Consolidation brings to the traditional spreadsheet. At the same time,
both versions will benefit from integration with separately licensed SAP BusinessObjects BI tools and EPM applications.
For instance, Xcelsius, SAP BusinessObjects Voyager, SAP BusinessObjects Web Intelligence, Crystal Reports and SAP
BusinessObjects Explorer can all be used as reporting and analysis alternatives to the native Microsoft Excel interface.

However, the proper leveraging of the familiarity of Microsoft Excel, the enterprise scalability of SAP NetWeaver and
the utility of SAP BusinessObjects BI solutions demand governance in the use of SAP BusinessObjects Planning and
Consolidation. More importantly, customers must deploy a comprehensive data strategy beyond just platforms and tools.

The version for SAP NetWeaver distinctly enables data and process integration with other SAP applications at
enterprise-level volumes. The version for SAP NetWeaver can reduce IT complexity by eliminating the need for
spreadsheet silos, departmental infrastructure, and separate deployments for financial planning, budgeting, forecasting
and consolidation.

For those organizations that have de facto standardization and governance build around the SAP NetWeaver technical
platform, one value proposition is clear. SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver,
creates additional synergies by further leveraging the accompanying organizational structures, operational procedures
and technical skill-sets based on SAP NetWeaver.

3. Creating Value with the Application
1. Following A Roadmap Framework for Delivering Enterprise Value
1. Leveraging the Platform – Data – Process Approach to Value
The typical vision for a performance management system involves an integrated closed-loop process consisting of top-
down strategy and bottom-up execution. At the heart of performance management is financial governance. The “Office
of the CFO” needs to define value and how to measure it in order for other business functions to map performance-
to-value creation. While the business struggles with the leadership needed for such a holistic endeavor, IT can work on
foundational elements for the system in incremental phases.

For context, this paper proposes a conceptual framework which extracts value by focusing on three different areas of
concentration that reflect increasing levels of effort (see Figure 1). While the vendor focus continues to be integrating
and strengthening the platform, exploiting those improvements is the easiest place for customers to start. Data
mapping continues to be more of a customer-driven activity facilitated by the platform. While most implementations
tend to be General Ledger-centric, more sophisticated mappings are necessary to bridge operations with finance. Both
vendor and customer must work together on how to best integrate data with management processes and workflows



across the enterprise, to achieve
business desires such as balanced
scorecarding, fast financial close
or rolling reforecasting.
All three of these areas of
concentration interrelate, but each
has differing weights depending
Integrated Business Processes upon the scope of the initiative.
The pet specialty retailer chose to
leverage the platform for reporting
VALUE

and analysis, with emphasis on
profit and loss data from the
General Ledger. The retailer
deferred the scope of process
Integrated Data integration with other systems in
order to stay within a tight budget.
In contrast, the consumer products
company invested much more
Integrated Technical Platform deeply in integrating business
processes and driver-based models
on global scale, with an eye on
INVESTMENT holistically assimilating SAP ERP
and SAP BusinessObjects Planning
and Consolidation into enterprise
Figure 1. Investment/Value Framework for a Platform-Data-Process Roadmap
planning and reporting processes.

2. Making Platform Integration Decisions
1. Why SAP NetWeaver BW is inseparable from SAP ERP
Whether or not organizations that run SAP ERP choose SAP as their vendor for Enterprise Performance Management
(EPM), they will need to use SAP NetWeaver BW for any enterprise-scalable design. If the scope of an initiative is tightly
restricted to a departmental BI or PM application, then middleware can connect to SAP ERP directly, but this non-
scalable approach carries many caveats. For example, reduced data latencies and large volumes of data movement are
difficult to achieve without SAP NetWeaver BW, for the following reasons:

1. Prepackaged Content. SAP delivers unparalleled breadth and depth in pre-delivered extractors (so-called “BI
Content”) that come with the SAP ERP system3. But these extractors only point to SAP NetWeaver BW, and
are technically difficult to “hijack” for use with other targets. These extractors were developed by the same
teams that developed the SAP applications that store the data, helping ensure tight integration and support for
application-specific complexities. Even narrowing the scope of extraction to the SAP financial applications, there
still exist two main challenges: data complexity and data latency.

2. Complexity. Financial applications have some of the most complex extractors in the SAP NetWeaver software
system, particularly the controlling (CO) functionality. In fact, a common approach to extract data out of SAP ERP
for departmental approaches is to leverage a custom SAP ERP report to do a manual file extract to avoid involving
those complexities. The document-level tables are easier to read but require an Extract, Transform and Load (ETL)
tool that knows how to generate ABAP,™ the SAP proprietary programming language. (SAP does not support
direct connection to the SAP database tables, mainly because of compressed formats and caching mechanisms).
Furthermore, these third-party tools can typically only perform full-load refreshes of current fiscal period data,
which can have significant performance implications. Even in instances where date and timestamps can be found on
transaction records, they are unreliable, and at best a “safety delta” concept must be employed where redundant
data must be purposefully extracted and reconciled in order to make sure all records are captured.



3. Data Management. In addition, SAP NetWeaver BW possesses “Open Hub Services,” where the results of
extraction can be passed straight through to a file or a database table on the SAP NetWeaver BW server.
This enables leveraging of job scheduling and workflows, known as “process chains.” SAP ERP lacks such
data management capabilities, which makes Open Hub Services a compelling reason to use SAP NetWeaver
BW as a proxy to the source SAP ERP. The challenge of third-party (non-SAP) EPM applications is that these
products have their own middleware and BI foundation layers. These additional data stores create architectural
redundancies and increase data latency times. While SAP BusinessObjects Planning and Consolidation, version
for SAP NetWeaver, is embedded in SAP NetWeaver BW, other products have separate server environments that
sit outside of SAP NetWeaver BW (see Figure 2).

EPM Applications BI Applications

Business Intelligence Foundation

Middleware

SAP BusinessObjects Planning and
SAP NetWeaver BW Consolidation, version for SAP NetWeaver

SAP NetWeaver BW

SAP ERP Non-SAP Sources SAP ERP Non-SAP Sources

Figure 2. Enterprise Performance Management Architectural Comparisons

2. Assessing the Oracle Hyperion Applications
Typical evaluations of Oracle Hyperion products versus SAP BusinessObjects Planning and Consolidation ultimately
depend on organizational strategy, not software functionality differences. “Check-the-box” evaluations of features and
functions between Oracle and SAP typically show parity in the areas of financial planning and financial consolidation.
This parity is not surprising, considering that Outlooksoft was founded by former Hyperion senior executives in 1999.
Hyperion even sued Outlooksoft in 2004 for two alleged patent infringements; the suits were not upheld.

Of course, deeper and more comprehensive technical analysis yields more significant differences and preferences.
Generally, the evaluative criteria that typically tilt the scales towards SAP BusinessObjects Planning and Consolidation are:

1. One product for both financial planning and consolidation. While Hyperion has separate products for financial
planning and financial consolidation, SAP BusinessObjects Planning and Consolidation uses the same platform
(i.e. common database, logic engine and user interface) to support both. As both processes typically serve the
same user communities, a single application obviously reduces change management and system administration.



2. Degree of Microsoft Excel integration. While most applications integrate Microsoft Excel as adjunct functionality,
SAP BusinessObjects Planning and Consolidation was designed and built around Microsoft Excel. SAP
BusinessObjects Planning and Consolidation uses Excel not only as a unified planning and reporting interface,
but a common tool to maintain master data, define transformation mappings and build custom administrative
and user applications. Furthermore, SAP BusinessObjects Planning and Consolidation has direct application-
specific intelligence for Excel, such as handling time and version-dependent consolidation hierarchies or
integration into workflows. In contrast, products such as Oracle Hyperion Smart View for Office act as a broader
BI tool, utilizing various providers or a middle-tier layer to interface with underlying EPM applications.

3. Real-time multi-dimensional data. SAP BusinessObjects Planning and Consolidation offers immediate
calculations and changes to data for reporting, analysis and even iterative planning, without the need to wait for
database processing activities. The next section on Hyperion Essbase will further explore this aspect.

Beyond these considerations, strategic and political forces, such as vendor versus customer roadmaps, vendor
relationships, vendor footprint and organizational adoption, usually play a more significant role in software selection.

Oracle Hyperion offers two financial consolidation products: Hyperion Enterprise (HE), which targets the midmarket,
and Hyperion Financial Management (HFM). HFM is a more apt comparison to SAP BusinessObjects Planning and
Consolidation as it is more scalable and comprehensive than HE. For example, HE can be migrated to HFM to address
constraints in dimensionality, inter-company elimination auditing, data-entry-screen design and process control4.

Hyperion Planning is the comparable software for financial planning. However, it should not be confused with
Hyperion Essbase, just as SAP NetWeaver BW should not be confused with SAP BusinessObjects Planning and
Consolidation. Hyperion Planning runs on Hyperion Essbase. This is an important distinction to make, as customers
sometimes confuse custom-developed Hyperion Essbase solutions as a vendor product. Even Hyperion Planning does
not exploit all the underlying functionality in Hyperion Essbase, and would have trouble displacing highly-specialized
homegrown applications.

3. Assessing the Hyperion Essbase OLAP Engine
The first version of Essbase shipped in 1992. While the OLAP technology is undeniably mature, it does suffer under the
weight of evolution that newer technologies can potentially disrupt or extend, such as in the case of SAP NetWeaver BW
Accelerator and Oracle’s HyperRoll aggregation engine, respectively.

The primary consideration is Essbase’s original storage mechanism known as “Block Storage Option,” or BSO.
Behaviorally, it is akin to MOLAP (as opposed to ROLAP — see Appendix for an explanation of these terms). More
specifically, the limitation with BSO is that it cannot effectively handle large volumes and large dimensions, especially
with sparsity. This translates into poor data latency (i.e. prolonged times to load and pre-calculate the BSO to make
data updates available). For financial applications that typically have dense models (i.e. low dimensionality and low data
volumes), BSO is not a significant constraint, but for logistical and operational applications with sparse models, it is not
the most effective long-term solution.

In 2005, Essbase addressed these limitations with the introduction of “Aggregate Storage Option” or ASO. While ASO
addressed the performance constraints of BSO, it introduced new complexities, such as:

1. Additional administration. Administration effort includes, but is not limited to, the manual tagging of each
dimension in each cube as either “dense” or “sparse” in order to manage the tradeoffs between BSO and ASO.

2. Lacking functionality. ASO has yet to reach BSO parity, missing functions and features in write-back and
calculation.

Consequently, Hyperion Planning only leverages Essbase BSO, not ASO, and thus suffers similar constraints found in
MOLAP, such as increased latency for data updates.

In contrast, Hyperion Financial Management (HFM) is based on an RDBMS arranged as a star schema. As a result, it
more resembles ROLAP, but does not have parity with the Essbase OLAP functionality. (However, many reporting and



analysis tools are commonly shared between HFM and Hyperion Planning.) There is also an option to load Hyperion
Essbase from HFM for reporting and analysis, but this also increases data latency due to load times involved.

Essbase ASO was insufficient on its own, as evidenced by Oracle’s announcement on September 29, 2009 that it
agreed to acquire certain HyperRoll assets5. The HyperRoll product acts a server plug-in that performs on-the-fly, high-
performance aggregation and query acceleration, and its acquisition can be viewed as a competitive response to SAP
NetWeaver BW Accelerator. Through HyperRoll’s Live Link product, Hyperion Essbase can almost instantaneously access
the HFM relational database.

How much HyperRoll will extend Hyperion Essbase beyond Live Link remains to be seen. In fact, Essbase ASO was
similar enough to HyperRoll to trigger a patent infringement law suit. In 2005, HyperRoll filed a suit against Hyperion
over the Essbase ASO technology; the suit was eventually settled.6

4. Assessing the SAP NetWeaver BW OLAP Engine
HyperRoll is not an OLAP engine. That work is performed by Hyperion Essbase. Ultimately, data latency and its impact
on end-user experience are a result of both the database and OLAP processing times.

While SAP NetWeaver BW Accelerator did not start as an OLAP engine, it is poised to become one, taking on functions
such as ranking, exception aggregation, top and bottom N conditions, write-back and planning services.

SAP NetWeaver BW Accelerator currently takes advantage of three techniques for high-performance access to data:
column stores, memory and massive parallel processing (MPP). Column stores simply store data vertically as opposed
to horizontally. Relational databases are row-oriented; they are born of the need to handle online transaction processing
(OLTP) volumes where business events are generally recorded and viewed a few rows at a time. However, to aggregate or
drill down on the same data, column-oriented databases are far more efficient, for the simple reason that only relevant
columns are scanned, rather than all rows and columns. Also, data in columns usually achieve much higher compression
ratios because of their natural uniformity. For star schema data models, column stores offer another approach to
MOLAP, ROLAP and HOLAP. Finally, SAP has partnered with hardware vendors to take advantage of MPP, also known as
“grid computing” or “blade servers”. As opposed to symmetric multi-processing (SMP) hardware, MPP hardware scales
linearly and has theoretically limitless growth.

But the method that holds most promise for improving end-user experience is in-memory analytics, not simply query
acceleration. SAP NetWeaver BW Accelerator is well positioned to apply memory to more facets of an application, like
OLAP and planning services. The falling costs of memory have given rise to a host of new in-memory possibilities, and
competitor moves have validated the importance of in-memory solutions. For instance, Oracle acquired TimesTen and
IBM acquired Solid DB for in-memory relational databases. Cognos (now IBM) acquired Applix (now TM1) for in-memory
MOLAP-based planning when it already bought Adaytum for planning. But so far, in-memory solutions have focused more
on the database than the application.

This has also been true of SAP NetWeaver BW Accelerator and the SAP NetWeaver OLAP engine, where SAP NetWeaver
BW Accelerator acts as a mirrored database and OLAP processing is done in ABAP. Without SAP NetWeaver BW
Accelerator, SAP NetWeaver BW is distinctly ROLAP.

As a result, SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver, is database-independent; that
is, it can run on any relational database management system (RDBMS) that SAP supports. Moreover, it can handle large
dimensions (i.e. master data) and support a high number of dimensions and a great degree of sparsity.

But there is a tradeoff with this flexibility. SAP NetWeaver BW shares classic ROLAP drawbacks: the requirement
of additional processing, due to star schema join operators, and the logic of an analytic engine. Furthermore, SAP
NetWeaver BW calls an MDX processor before executing the analytic engine. Much of this is mitigated by sparing
use of MDX formulas in the SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver, in favor of
other platform strengths, such as ABAP programming extensibility. Additionally, because the solution has a Services-
Oriented Architecture (SOA), additional back-end improvements are easier to implement without disrupting the SAP
BusinessObjects Planning and Consolidation application itself. Case in point: plug-in of SAP NetWeaver BW Accelerator.



Figure 3 below depicts a summary of comparisons, demonstrating that various products which have taken different
OLAP approaches lead to different tradeoffs. The MOLAP-versus-ROLAP-versus-HOLAP debate has no clear victor. On
the other hand, columns stores and in-memory storage seem to have an edge, but not without drawbacks such as write-
back performance for column stores or disaster recovery for in-memory storage. Of course, the quality of the actual
implementation is another major aspect that should not be overlooked when performing evaluations.

Storage Types and Application Behaviors

Primary
Storage MOLAP ROLAP HOLAP+ COLUMN STORES
Mediums

SAP NetWeaver BW
Microsoft Analysis Accelerator and SAP
MEMORY Cognos TM1 SAP APO, liveCache Services (in memory BusinessObjects
for MOLAP only) Planning and
Consolidation*

Hyperion Essbase
HFM, SAP
BSO and ASO, SAP
Hyperon Planning BusinessObjects
PHYSICAL HyperRoll Planning and
BusinessObjects SAND Nearline
Planning and
Consolidation*
Consolidation**

* The version for SAP NetWeaver
** The version for the Microsoft platform
+ HOLAP also includes MOLAP and ROLAP as well as both simultaneously

Figure 3. Storage approach matrix for categorizing applications and underlying OLAP technology

5. How the Application Simplifies Database Complexities
While most OLAP-based analytic applications require database-centric skills to design and maintain, SAP’s three-tier
client-server architecture has always abstracted the intricacies of the database by pushing design and maintenance
up to the application layer. The three-tier approach has afforded SAP flexibility and portability without restricting
enterprise performance scalability. More specifically, SAP BusinessObjects Planning and Consolidation, version for
SAP NetWeaver, will automatically generate and maintain all the underlying SAP NetWeaver BW metadata, which in
turn generate ABAP dictionary objects and, later, database objects. The application design specialist replaces the data
modeler. In contrast, custom Essbase solutions require more database-centric skills.

This approach shields the business from the workings of the SAP NetWeaver BW system. Designers and operators are
thus free to focus on Microsoft Excel within the SAP BusinessObjects Planning and Consolidation application framework,
leaving IT to worry about the infrastructure considerations.

Another example where data level complexities are abstracted away from designers and administrators is in the area
of data locking. More specifically, the data writes directly into the SAP NetWeaver BW OLAP database, known as an
“InfoCube,” via an application-specific interface that employs its own automatic locking algorithm. The locking mechanism



was designed for enterprise-scalable performance and zero maintenance. In SAP NetWeaver BW BPS and SAP NetWeaver
BW IP, the locking algorithm had to be defined upfront and administered because of the potential for performance
bottlenecks. In the SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver, locking is founded more
on the principle of “use what you need when you need it,” where a lock is created just in time to perform a write-back.
As a result, the last person to save, “wins.” Potential user conflicts can be more appropriately controlled by governed
workflows and security. Businesses can mitigate the risk of conflict via data regions within Business Process Flow steps,
organizational data slices in Work Status definitions, or defined data access in Member Access Profiles.

Note that alternative planning, budgeting and forecasting applications typically push down business logic and
calculations to the database. For instance, Essbase has its own embedded business and statistical algorithms. In the
SAP BusinessObjects Planning and Consolidation, version for the Microsoft platform, much of the heavy financial logic
is defined in SQL Server database stored procedures. In the version for SAP NetWeaver, nothing is ever developed
directly in the database; rather, it must be programmatically defined in the application server. As a result, custom
logic that normally would be implemented as a database-stored procedure is instead coded in ABAP. There are hooks
in SAP code that allow for custom extensions known as “Business Add-Ins” (BADI). For SAP environments with ABAP
development skills, this is a familiar approach for extending SAP applications. BADIs can be called via special commands
within flexible scripting language, known as “Script Logic.” Otherwise, there are standard commands in Script Logic, and
special commands linked to configuration tables known as “Business Rules,” that reduce the dependence on ABAP.

6. Assessing how the Application Exploits its Own Platform
In SAP NetWeaver BW, the data movement, and its associated workflow logic and administration functions, is controlled
by process chains. These process chains can orchestrate functions including extraction, data transfer, data deletion,
aggregate build, index recreation, refresh of DB statistics and InfoCube fact table compression.

SAP BusinessObjects Planning and Consolidation capitalizes on this pervasive tool in SAP NetWeaver BW by linking it to
its own unified batch scheduling mechanism, known as “Data Manager”. The Data Manager is designed for the business
to own, maintain and operate the application with standard packages pre-delivered for most needs. Examples include
administration functions, data management and execution of Script Logic, such as allocations, currency translation,
balance carry-forward and intercompany eliminations.

Customizing or extending a Data Manager package requires distinctly different technologies and skill sets, depending
on the platform version. In the version for the Microsoft platform, custom SQL Server Integration (SSIS) packages
must be created, while in the version for SAP NetWeaver, process chains must be developed. Process chain technology
has the advantage of automated end-to-end flow of SAP ERP-based extractions to SAP BusinessObjects Planning and
Consolidation uploads in one job schedule. SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver,
has its own process chains, which can also be integrated with the classic SAP NetWeaver BW process chains.

In addition to RDBMS independence, SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver,
enjoys operating system independence. It does this by technically storing files in the database via what it calls “File
Service.” File Service is an SAP NetWeaver-based application that mimics the file structure maintenance operations of
an operating system like Microsoft Windows, but offers its own unique functions and features.

File Service stores files in a compressed format, using the freeware GNU Zip compression method. It also has the ability
to upload, download, and virus-scan multiple files into one zipped file at once. There are two formats in which it stores
data: binary large objects (BLOBs) and generated tables. BLOBs are a common medium, not specific to SAP, designed
to store large files such as Microsoft Office documents. In contrast, generated tables are specifically designed for SAP
BusinessObjects Planning and Consolidation functions that need to read data row-by-row, such as transformations and
conversions or data extract files. The data stored in this table are text strings, with a record for each row in a file, as
in a common-delimited format. This table format makes these files faster to read. Another interesting SAP NetWeaver
feature is the ability of administrators to lock and unlock files from use.

Finally, perhaps the most significant benefit to the File Service functionality is the ability to transport specific folder
structures and files in conjunction with an SAP BusinessObjects Planning and Consolidation application set. For example,
File Service transports supports wildcards to limit files to a specific file type.



The overall SAP BusinessObjects Planning and Consolidation integration with the SAP NetWeaver transport
management system in and of itself is a unique differentiator. This integration enables robust change control
mechanisms for enterprise needs, including status tracking and audit trails. While the entire application set must be
transported at once, the workflow thereafter follows the same rigor as all other transports in an SAP system to help
ensure integrity. While the transport is large from a logical perspective, it is not large technically, as the underlying
physical structures are generated in the target system from transported metadata definitions upon importation. In
addition, transporting the entire application set greatly reduces the complexity of managing object dependencies in
the promote-to-production path. However, for multiple developments within an application set, this may force a level of
undesired central coordination and synchronization of releases amongst developers.

Version control is also handled somewhat differently, where only the latest version of the SAP BusinessObjects Planning
and Consolidation, version for SAP NetWeaver, application set is transported even if multiple transports are created
at separate times. This is because there exists a single set of shadow tables used for transports, and this set gets
overwritten when each transport is created. This stands in contrast to other non-enterprise scalable methods such as
manual replication via exporting and importing, or even the use of back-up and restore recovery processes to promote
objects from development to production.

Note that because much development is done within Microsoft Excel itself, there is also flexibility to handle change
control outside the File Service and SAP transport management system. The business has the option to download and
upload its Microsoft Excel files across the system landscape. Only back-end developments need to be transported for
each application set.

The integration into the SAP NetWeaver technical platform also extends into Solution Manager. Having a standardized
mean for importing fixes, applying patches, reading logs and troubleshooting across all SAP solutions, including SAP
BusinessObjects Planning and Consolidation, version for SAP NetWeaver, reduces both risk and total cost of ownership.
In addition, performance monitoring is directly integrated into the native and comprehensive SAP NetWeaver BW
statistics tracking functionality. This enables a wide view on system performance from the SAP BusinessObjects
Planning and Consolidation application layer down to the SAP NetWeaver BW platform layer.

7. How to leverage the SAP BusinessObjects BI integration
For both Microsoft and SAP NetWeaver versions of SAP BusinessObjects Planning and Consolidation, the primary
integration touchpoint for the SAP BusinessObjects BI solutions is an OLE DB for OLAP (ODBO) Provider. The
ODBO Provider enables SAP BusinessObjects Voyager, Crystal Reports, SAP BusinessObjects Web Intelligence,
SAP BusinessObjects Explorer, and Xcelsius, though each in different ways. SAP BusinessObjects Voyager has
the native ability to directly connect to ODBO providers. Crystal Reports, SAP BusinessObjects Explorer and SAP
BusinessObjects Web Intelligence are designed to connect to the ODBO provider via an OLAP Universe. Xcelsius
indirectly connects to the ODBO Provider via the extended analytics analyzer in SAP BusinessObjects solutions and
an Xcelsius add-on known as the EPM connector. The extended analytics analyzer is similar to the SAP Business
Explorer (SAP BEx) analyzer tool in that it enables Microsoft Excel-based access to OLAP sources (albeit ODBO-
compliant sources). The EPM connector leverages an XMLA service to enable a zero-client, live data connection at
runtime, and is a custom component within the Xcelsius designer tool.

There is also single-sign on integration between the SAP BusinessObjects Enterprise software server and the SAP
BusinessObjects Planning and Consolidation server. This enables additional single-sign options beyond Windows
Active Directory (AD) services, not only for reporting and analysis in SAP BusinessObjects solutions but without it for
everyday SAP BusinessObjects and Planning and Consolidation usage. In such a scenario, the user management system
in SAP BusinessObjects solutions, a trimmed-down version of the Central Management Server at the heart of SAP
BusinessObjects Enterprise, is included with SAP BusinessObjects Planning and Consolidation. This user management
system enables the use of LDAP, AD, SAP BusinessObjects Enterprise and SAP authentication options, while the SAP
BusinessObjects tools and complete SAP BusinessObjects Enterprise environment are separately licensed.

New dashboarding, reporting and analysis, both web-based and Excel-based, are available to SAP BusinessObjects
Planning and Consolidation users. Deciding on the right tool for the right job thus becomes another governance
exercise. Generally, if very specific integration into the application is necessary, then the Microsoft Excel client in SAP
BusinessObjects Planning and Consolidation will remain the best tool. For example, the Microsoft Excel client leverages


the “Dynamic Hierarchy Editor” for making time- and version-dependent mapping of reporting groups to entities for
which only the SAP BusinessObjects Planning and Consolidation client for Excel has the intelligence. The ODBO provider,
in contrast, is designed for broader BI needs. For example, use cases may include extending data access to a larger user
community beyond the realm of finance and Microsoft Excel, batch printing, mass publications, report bursting and
combining data with outside sources within a single report.

8. SAP NetWeaver BW BPS and SAP NetWeaver BW IP Considerations
For financial planning, budgeting and forecasting, SAP has a history of products that have created some redundancies in
their portfolio. But these products have also created new opportunities for hybrid scenarios. For example, planning has
been a part of SAP ERP since its inception, with direct integration across functionality such as Manufacturing Resource
Planning (MRP) and cost center planning. (After all, ERP stands for Enterprise Resource Planning.) And SAP ERP
financial planning has its own closed-loop processes, as demonstrated in the controlling–profitability analysis (CO-PA)
functionality, making it attractive to leverage.

Apart from the roadmap history and any additional future considerations, there are important architectural and design
comparisons to be made. Such comparisons help facilitate analysis of the options and where applicable, migration
considerations.

Because SAP SEM maps to SAP NetWeaver BW as distinct and separate applications, there is redundant metadata. For
example, in the legacy product SAP SEM BPS the SEM variables are different objects from SAP BEx variables. Because
they are so similar in concept, some implementations integrated the two by custom programming. “Transactional” or
“Real-time” InfoCubes are linked to SAP SEM BPS planning areas and could actually reside in a separate but connected
system. SAP SEM BPS has its own planning user interfaces, either delivered through the SAP GUI or the web. (Microsoft
Excel functionality is delivered as a component inside one of these two mediums rather than a standalone option.)
While SAP BEx tools can be used against InfoCubes used in SAP SEM BPS, they are not designed to integrate with the
BPS user interface tools in the front end. SAP SEM BPS has its own front-end technology, using planning layouts for
assembly into planning folders that in turn generate business server pages or BSPs (i.e. extensible SAP NetWeaver-
based web applications) via a tool known as Web Interface Builder.

When SAP SEM BPS was rebranded to SAP NetWeaver BW BPS, its architecture and design essentially remained the same.
This highly-layered and architected approach stayed in place until a more integrated approach was taken eliminating
the need for SEM variables, planning areas, planning layouts, planning folders and the Web Interface Builder. Finally,
background scheduling of planning functions was migrated to process chains instead of using global planning sequences
(see Figure 4).

But even this more integrated platform approach (hence the name “SAP NetWeaver BW Integrated Planning”), didn’t
eliminate the need for planning levels (renamed aggregation levels), planning packages (renamed filters), planning
functions, parameter groups (renamed parameter sets and conditions), and planning sequences. In fact, it explicitly
borrowed and migrated functionality to the new embedded platform such as FOX (SAP’s scripting language for planning)
and forecasting planning functions, data slices (for locking data) and characteristic relationships (for referential
integrity). These additional metadata components were added to the SAP NetWeaver BW repository. The most visible
difference between SAP NetWeaver BW IP versus SAP NetWeaver BW BPS is the ability to use SAP BEx analyzer (in
Microsoft Excel) and SAP BEx Web application designer (on the web) as the unified tools for both planning and reporting.

The “law of parsimony” states that the simpler of two solutions should win. Accordingly, SAP BusinessObjects Planning
and Consolidation has an edge by eliminating the need for defining variables, aggregation levels, filters, parameter
sets, planning sequences and queries altogether without compromising functionality. In fact, it adds functionality more
relevant to financial planning. It does so via a feature known as the “Current View” of the “Action Pane” displayed within
spreadsheets for application context.

SAP BEx variables were designed for executing queries, not planning. As a result, using SAP BEx variables in Integrated
Planning can be problematic, since the user-set values are cached, but are cleared from memory every time the user moves
to a new query. The SAP BusinessObjects Planning and Consolidation current view does not suffer that limitation and is
available for every dimension in the user’s application eliminating the need to define variables. In addition, because every
dimension is available for selection from within the current view, this eliminates the need for aggregation levels and filters.


Similarly, planning functions are replaced by keywords in Script Logic files and do not need to be defined for every
aggregation level and filter; Script Logic is application set-dependent (i.e. available across InfoCubes). Furthermore,
Script Logic can be re-used within itself via “INCLUDE” statements. SAP NetWeaver BW IP planning functions can only
be combined sequentially in planning sequences, not hierarchically or embedded.

Beyond the Current View of the Action Pane, there are many other ways to control how data is selected in the
application without the need for additional metadata objects, as in SAP NetWeaver BW IP, while at the same time
providing greater flexibility. For example, the Current View of the Action Pane can be overridden in an input schedule
or report at the workbook, page, column, row and cell levels. User prompts within Data Manager as well as Script Logic
keywords also eliminate the need for aggregation levels and filters. More specifically, data sets can be controlled via
scoping keyword statements, either statically (i.e. hard-coded) or dynamically (i.e. via variables set programmatically or
external values such as Data Manager prompt values).

In SAP NetWeaver BW IP, parameter sets are used to configure planning functions while advanced commands in Script
Logic are configured by Business Rules. While conceptually similar, parameter sets and Business Rules are technically
quite different. Business Rules are used for commands with additional customizable logic behind them, such as
consolidation of investments, balance carry-forward or currency translation. They are centrally maintained, while SAP
NetWeaver BW IP parameter sets are aggregation level, filter and planning function-dependent. Furthermore, Business
Rules are not always needed, as is the case for parameter sets. The parameters of some logic, such as allocations, are
defined in the Script Logic keyword command itself.

Furthermore, Script Logic itself is not always necessary to perform centralized calculations. SAP BusinessObjects
Planning and Consolidation has a concept foreign to SAP NetWeaver BW: “Dimension Logic” or “Member Formulas.”
Master data can be created which is in itself a calculation, such as gross margin or revenue per-capita accounts. This
logic is missing in SAP NetWeaver BW BPS and SAP NetWeaver BW IP because it is handled by the MDX processor
external interface rather than the native OLAP engine.

While Dimension Logic should be used judiciously, the Excel interface for SAP BusinessObjects Planning and Consolidation
should be used aggressively as another way to reduce back-end complexity. Compared to the Microsoft Excel-based
interfaces in SAP NetWeaver BW BPS and SAP NetWeaver BW IP, SAP BusinessObjects Planning and Consolidation,
version for SAP NetWeaver, has many more options for Excel. Besides macros and Visual Basic for Applications (VBA)
programming, there is a library of Microsoft Excel functions specific to SAP BusinessObjects Planning and Consolidation to
make spreadsheets more dynamic without the need to code.

All in all, SAP BusinessObjects Planning and Consolidation has significantly less back-end metadata to maintain
compared to SAP NetWeaver BW BPS and SAP NetWeaver BW IP, thereby speeding up development, facilitating
migration and simplifying administration (see Figure 4, where the cross marks represent the reduction in metadata).

Another key difference between SAP NetWeaver BW BPS, SAP NetWeaver BW IP and SAP BusinessObjects Planning and
Consolidation is where the work of development is being done. In SAP NetWeaver BW BPS the development work is being
done bottom-up. The first layer consists of designing, building and loading InfoCubes in SAP NetWeaver BW. The second
layer consists of designing, building and planning against all the relevant planning objects belonging to a planning
area. In SAP NetWeaver BW IP, all the development work is embedded in SAP NetWeaver BW itself. Aggregation levels,
filters and planning functions are relatively new objects to SAP NetWeaver BW, but are tightly integrated into SAP BEx.
Queries can be designed to read and write against specified aggregation levels and filters, while SAP BEx workbooks and
web applications can be designed with push buttons to call planning functions and sequences. Finally, the work in SAP
BusinessObjects Planning and Consolidation is being built top-down, with no requirement to make modifications in the
SAP NetWeaver BW layer at all.

All the design and development work can be done from within the SAP BusinessObjects Planning and Consolidation
admin console, which automatically generates all the necessary SAP NetWeaver BW objects and keeps them up-to-
date. As noted above, none of the SAP NetWeaver BW IP plumbing or metadata was leveraged, as it was not needed for
the new streamlined design. Where SAP NetWeaver skills come into play is in the development of any custom process
chains needed to run Script Logic, perform data loads, or execute administration functions and the coding of BADI logic
in ABAP. Of course, “getting under the hood” is also needed for expert troubleshooting, debugging and performance
optimization, as is the case for any application.



SAP BusinessObjects Planning
SAP NetWeaver BW BPS SAP NetWeaver BW IP and Consolidation, version for
Components Components SAP NetWeaver, Components
(Bottom-To-Top Build) (Embedded Build) (Top-To-Bottom Build)

SAP SEM Variables
X SAP BEx Variables
X
Data Slices / STS Data Slices / STS Work Status

Characteristic Characteristic
Validations
Relationships Relationships

Planning Area
X InfoProvider Application

Planning Level Aggregation Level
X
Planning Package Filter X

Planning Function Planning Function
X Logic Scripts

Parameter Group Parameter Sets
X
Planning Sequences Planning Sequences
X
Global Planning Sequences
X Process Chains Process Chains

Planning Layouts
X SAP BEx Queries

Planning Folders X
X
BPS Web Interface Builder SAP BEx Excel analyzer and SAP
BEx Web application designer
Excel interface for SAP BusinessObjects
Planning and Consolidation

Figure 4. Architectural Comparisons of SAP Planning Applications

3. Making Data Integration Decisions
SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver, is an analytic application that generates
a data mart in the user’s enterprise data warehouse environment. Greater technical integration between data mart
and data warehouse is achieved if both are on SAP NetWeaver BW, but does not eliminate the need for physically
different data stores and data mapping.



Different business domains and processes require their own data and models. For example, in SAP ERP there are different
modules for application areas that store their own master data and transactions. Configuration defines the mappings
between each module to achieve integration. Even shared master data, such as customer and product, are actually stored
as separate tables for the needs of each business function, such as a sales view versus an accounting view.

Likewise, SAP BusinessObjects Planning and Consolidation has its own separate master data and transaction data
needs. Application intelligence such as currency translation, intercompany eliminations, balance carry-forward, workflow,
account signage and formatting can be driven by values stored in master data. Additionally, different financial and data
modeling conventions are employed, such as periodic versus year-to-date handling, account signage and the storage of
quantities. As a result, the data mapping effort involved in an SAP BusinessObjects Planning and Consolidation project is
not fundamentally different to any other BI or data warehouse project from a data integration perspective.

Correspondingly, the data warehouse approach taken to achieve integration is up to the customer. While SAP espouses
its own reference architecture for enterprise data warehousing, a concept it calls “Layered Scalable Architecture,” or
LSA, there are customers who are bypassing data layers to improve latency, especially ones that do not have an already
established data warehouse on SAP NetWeaver BW.

Another important consideration is that SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver,
generates the data models in SAP NetWeaver BW automatically, as discussed earlier. In order to empower the business
to generate its own data mart without creating conflicts with current and future SAP NetWeaver BW developments, SAP
used a mechanism called a “namespace,” which physically separates SAP BusinessObjects Planning and Consolidation
metadata objects from SAP NetWeaver BW enterprise data warehouse metadata objects via a reserved prefix in the
technical name. So the need for data mapping is not just driven by business needs, but technical ones as well.

For IT-driven SAP BusinessObjects Planning and Consolidation implementations, the separate namespace and application
layer atop of it can represent a loss of control just as the SAP NetWeaver BW environment represents a loss of control
for the database modeler and administrator.

Irrespective of the approach taken, data governance considerations, like master data management, are an important
aspect of any analytic application implementation. While data redundancy is an inherent part of any data mart, master
data redundancy poses a separate challenge that typically necessitates a broader strategy and cross-application
middleware to address. SAP NetWeaver BW can cover some methods of use and implementation styles of master data
management, but is not a comprehensive master data management (MDM) solution itself7. Whether custom or off-
the-shelf, MDM systems are not designed to eliminate redundant master data, but rather centrally coordinate their
administration and standardize identifiers. In other words, it is possible, and even desirable, to achieve conformity
without having all master data physically reside in the same table.

Proper data mappings and master data governance is a vital cornerstone to achieving process integration with
applications and processes beyond SAP ERP, such as SAP SCM and SAP CRM.

4. Making Process Integration Decisions
The way to reap the most potential enterprise value from SAP BusinessObjects Planning and Consolidation, version for
SAP NetWeaver, is to leverage SAP NetWeaver as the common “Business Process Platform” with other relevant SAP
business applications. There is an abundance of SAP applications that SAP BusinessObjects Planning and Consolidation
can integrate with, including SAP CRM; SAP SCM; the SAP Product Lifecycle Management application; SAP ERP
functionality for financials, controlling, and human resources; the SAP Resource and Portfolio Management application;
the SAP BusinessObjects Strategy Management application; the SAP BusinessObjects Supply Chain Performance
Management application; and the SAP BusinessObjects Profitability and Cost Management application. While all the
business processes supported by these applications interrelate, it is important to understand that they all support
a variety of different purposes than the financially-oriented SAP BusinessObjects Planning and Consolidation. Put
differently, trying to replace, instead of complement, any of these applications with SAP BusinessObjects Planning and
Consolidation without deliberation would be ill-advised.

Furthermore, various SAP applications have their own technologies for defining workflows, business process steps
and process monitors, even within the area of financials. While SAP BusinessObjects Planning and Consolidation has



its own unified “Business Process Flows” for guiding financial planning, budgeting, forecasting and consolidation
activities, the controlling–profitability analysis (CO-PA) functionality within SAP ERP leverages the traditional and
core ABAP-based workflows. The CO–cost center accounting (CO-CCA) functionality in SAP ERP, SAP NetWeaver
BW BPS and SAP NetWeaver BW IP all can be integrated via a web-based “Express Planning” application. The SAP
ERP-based “Closing Cockpit” promises to bring all the execution activities together for local financial ledgers.
Meanwhile, operational reviews supported by SAP BusinessObjects Strategy Management are more appropriate for
strategic planning activities. While each technology achieves a level of cross-application integration in its own right,
the constraint to end-to-end, closed-loop, strategy-to-execution processes is more about business realities than
breakthrough technology. While academics have touted solutions like the “balanced scorecard” in the last decade or
two, these management frameworks have yet to be pervasively adopted by customers.

Irrespective of discordant business needs and various enabling technologies, if effective value governance is to be
instituted across the enterprise, ultimately the Office of the CFO must define and lead the way. It is up to finance to
translate corporate performance into standard practices, policies, models and metrics. While ERP can meet the demands
of traditional accounting, finance and the business units it governs demands a flexible and adaptive application it can
own and operate for ever-evolving corporate decision-making models.

The financial application best positioned to serve as the heart of any ambitious management framework and portfolio
of enabling technologies is SAP BusinessObjects Planning and Consolidation. The simple reason is that it gives
business process context and extended analysis functionality to the de facto management decision making tool today:
Microsoft Excel.

4. Conclusion
SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver, is an innovation that marries several
proven technologies (Microsoft Excel, Outlooksoft, SAP NetWeaver and and integration into SAP BusinessObjects
solutions) for two financial domains (planning and consolidation) into one product. Just as Microsoft Excel has become
the most pervasive decision-making tool, SAP NetWeaver has established itself as proven business process platform
for large enterprises. Integrating these technology capabilities enables new business capability options. Organizations
must now decide how to redefine governance to exploit co-creation opportunities where business and IT partner
together on work streams, as well as business self-service opportunities where IT passes control to the business for
greater autonomy, flexibility and adaptability.

In short, SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver, demands consideration from
customers who need any of the following:

• A unified planning, budgeting, forecasting and consolidation application that can be owned by corporate finance.

• An application that can be flexibly re-defined and adapted for enterprise agility.

• An application with a user-interface that the business can readily adopt and create value with.

• Integration into SAP transactional systems for timely, accurate and reconcilable reporting and analysis through
pre-delivered and customizable SAP NetWeaver BW content and drill-though functionality.

• Application Integration with other SAP solutions through the common SAP NetWeaver technical platform.

• Integration with SAP BusinessObjects Enterprise for BI platform standardization and enhanced reporting
and analysis.

• An infrastructure that is enterprise-scalable from performance, change control and administration perspectives.

• An application with an infrastructure designed for operating system and database independence.

• A solution that leverages pre-existing organizational capital such as SAP skill-sets and support structures to
trouble-shoot, monitor and tune.



5. About the Author
David Dixon is a Vice President of Research and Advisory at Business & Decision and one of the
international thought leaders to help garner Business & Decision recognition on the Gartner Magic
Quadrant for Global Business Intelligence and Performance Management Service Providers.

He co-authored the book “Mastering the SAP Business Information Warehouse” written with Bill
Inmon, the “father of data warehousing,” as well as authored white papers sponsored by Business
Objects and SAP. David started his career in 1995 as a Financials and Controlling (FI/CO) consultant
with SAP specializing in financial consolidations, product costing and profitability analysis with
particular expertise in the ERP information systems and tools.

David was a Platinum Consultant before he left SAP in 1999 to help form COMPENDIT, an SAP NetWeaver BW
consultancy startup. COMPENDIT was acquired by Inforte in 2004 and in turn, Inforte was acquired by Business &
Decision in 2007. Over the years, David provided leadership during the organizational transitions in all the facets of the
business spanning marketing, sales, innovation and delivery helping to foster a reputable brand in the SAP industry.

David has worked with SAP’s development team in Walldorf and Palo Alto on numerous occasions in support of
applications that can be characterized more recently as Enterprise Performance Management. He continues to have
active close ties with the SAP EPM Regional Implementation Group (RIG) where he mentored many of its current
members as his former employees as well as maintains close ties to the SAP NetWeaver RIG. He has extensive project
experience in implementing complicated global solutions for Fortune 100 companies and has presented at various SAP
and BI forums such as TDWI, SAP TechEd, SAP Insider and ASUG conferences. Recently, he wrapped up a two-years-
running SAP Insider seminar with SAP as the opening and closing speaker.

6. Acknowledgments
Special thanks to the following individuals:

• Ethan Jewett as a trusted source for information and acting as a sounding board for broader ideas.

• Jens Koerner for his implementation experiences as a project leader and thought leadership in the topic of data
integration and deployment options.

• Steve Brazeal, Hari Srinivasan and Gersh Voldman for their implementation experiences and technical knowledge.

• Bryan Katis, Scott Cairncross, Chris Pauxtis and Zane Connally for providing the support of the EPM RIG team.

• Prakash Darji for taking the time out of conferences to sit down and chat with me about the product he helped
to create.

• Steve Palmer for the executive support needed to balance this white paper with other demands.

• David Williams for his diligent review of the content.



7. Appendix
1. OLAP Explanation
One definition for On-Line Analytical Processing (OLAP) is another acronym, “FASMI,” short for Fast Analysis of Shared
Multidimensional Information. Those familiar with OLAP understand that there are different storage types of OLAP,
such as relational OLAP (ROLAP) versus multi-dimensional OLAP (MOLAP), as well as hybrids of the two (HOLAP). The
OLAP mechanism acts as the foundational base to applications like SAP BusinessObjects Planning and Consolidation
(both Microsoft and SAP NetWeaver versions), as well as competing products like Hyperion Planning, Hyperion Financial
Management and Cognos TM1. Many of the strengths and weaknesses of OLAP-based products are derived by the
OLAP analytic engine used. Not only will an understanding of the core OLAP technology help in designing, optimizing
and troubleshooting OLAP-based products, but some implementation work can be done at this core level such as
performance tuning, business calculations, data loading and application administration.

Much of the following discussion about OLAP performance is theoretical, and none of the comparisons have been well-
profiled across the specific applications noted. The debate between the advantages of ROLAP versus MOLAP has not
determined a superior option, but rather created a better industry understanding of the archetypal tradeoffs. Hybrid
OLAP, or HOLAP, is a manifestation balancing the tradeoff. The reality is that there are many performance-related
factors that extend well beyond ROLAP-versus-MOLAP considerations, such as partitioning, indexing, compression,
parallelization, caching and hardware. Perhaps the most important criteria to evaluate are how each vendor implements
its OLAP solution, and how analytic applications are using it. The key takeaways to understand are administrative
considerations as well as roadmap implications.

At risk of oversimplifying, MOLAP is typically much faster for dense data models like financial applications, but degrades
significantly for sparse ones, as in instances where many rows have blank columnar values, characteristic of data
merged from separate sources. In addition, MOLAP usually needs downtime to pre-calculate all the possible drill-down
combinations. ROLAP is typically better with sparsity and handling larger dimension tables because it is leveraging join
operations rather than persistently storing Cartesian products — i.e. an array made up of all the dimensions — but this
approach has its own runtime performance impacts.

8. References
1
Jutras, Cindy and Hatch, David. “Financial Planning, Budgeting and Forecasting: Managing in Uncertain Economic Times.” Aberdeen Group,
(January 1, 2009), http://whitepapers.sapinsideronline.com/view.cfm?session=33dd7056-7af2-4536-8c0b-6b98f53cb7e8&action=load&white_
paper=333
2
“Enterprise Architecture is a complete expression of the enterprise; a master plan which “acts as a collaboration force” between aspects
of business planning such as goals, visions, strategies and governance principles; aspects of business operations such as business terms,
organization structures, processes and data; aspects of automation such as information systems and databases; and the enabling technological
infrastructure of the business such as computers, operating systems and networks.” From “Enterprise Architecture Good Practice Guide First
International Open Standard in EA, http://www.enterprise-architecture.info/EA_Standards.htm
3
SAP NetWeaver 7.0 Help, BI Content, http://help.sap.com/saphelp_nw70/helpdata/en/3d/5fb13cd0500255e10000000a114084/frameset.htm
4
Cybulski, Robert. “Converting a Hyperion Enterpirse Application to a Hyperion Financial Management Application: Design Considerations and
Best Practices.” Oracle Application Users Group, http://www.finitsolutions.com/docs/Finit_HE_to_HFM_Collaborate2009.pdf
5
“Oracle Buys HyperRoll” Oracle Press Release, (September 29, 2009), http://www.oracle.com/us/corporate/press/034753
6
Sawyer, Stephen.===== “HyperRoll and Hyperion Settle Accounts.” TDWI, (October 18, 2006), http://tdwi.org/articles/2006/10/18/hyperroll-
and-hyperion-settle-accounts.aspx
7
Oberhofer, Martin and Dreibelbis, Alan. “An Introduction to the Master Data Management Reference Architecture.” IBM Technical Library, (April
24, 2008), http://www.ibm.com/developerworks/data/library/techarticle/dm-0804oberhofer/


Creating Value with SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver

More Related Content

What's hot

Viewers also liked

Similar to Creating Value with SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver

More from dcd2z

Creating Value with SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver