In 2007 SAP AG completed its first major acquisitions of software firms to increase its market share in the CPM market space. Originally SAP AG purchased the software vendor OutlookSoft and then later that year it acquired BusinessObjects.
These two acquisitions marked a major shift in SAP’s strategy from acquiring firms only for specific technologies to acquiring entire suites of tools with an established user base. These acquisitions however left SAP with overlapping tools within several market spaces. One specific market space was the Corporate/Enterprise Performance Management (CPM/EPM) market, where SAP offered several distinct tools: Business Planning and Consolidation (BPC), BusinessObjects Financial Consolidation (BFC), BusinessObjects SRC and SAP Business Consolidation System (SEM-BCS).
Going forward, SAP will provide updates for SRC and SEM-BCS only until the end of 2013; thereafter, all investment by SAP will be focused on BPC and BFC for the EPM market space. Consequently, this article will focus solely on the differentiators and similarities of BPC and BFC so that the reader may be able to gain a better insight into SAP’s EPM offer and why a company would select one tool over another to support the various activities of their finance function.
Furthermore, we have done our best to avoid vague marketing terms such as "best in class calculations” or "mature and sophisticated software solution” in this comparison; rather it will be based upon experience from multiple implementations with both of these tools. In order to make this article as relevant as possible, we will also focus on how BPC and BFC differ in supporting the specific functional initiatives that a finance department may undertake rather than documenting a list of specific technical bullet points.
Evolution of the products prior to SAP’s acquisitions
Since their acquisitions in 2007, SAP has definitely had significant impact on these two tools, but the original visions and the intended target markets -of the two original software vendors who created them- are still at the core of how they function.
BFC was originally developed by the French software vendor, Cartesis under the brand name Magnitude. Cartesis itself was acquired by BusinessObjects in 2007 prior to SAP’s takeover of BusinessObjects. This tool was originally developed to support the statutory consolidation requirements of corporations on the CAC-40, France’s principle market index. In general, these corporations are large multinationals with multiple business segments and have complex ownership structures relative to their peers in other markets. Consequently, Magnitude and subsequently BFC evolved in a manner which allows it to support these very complex statutory consolidation requirements that arise due to the business models of these companies, but at a detriment to other reporting requirements such as budgeting or costing requirements.
On the other hand, BPC originated from developers who left Hyperion Solutions and formed the software vendor OutlookSoft in the United States. The company’s original vision was that Microsoft SQL Server and it various components already provided much of the necessary functionality for data integration, calculations, data storage and reporting requirements compulsory for an EPM tool. By utilizing SQL Server’s components (SSAS, SSRS and SSIS) plus Microsoft Excel as an interface for reporting, Outlooksoft could deliver a rich level of functionality that is capable of handling a wide range of reporting requirements that a finance department may face. MS Excel was an integral part of this solution because it provides a familiar interface as a reporting tool for a finance team, it provided a level of functionality well beyond a bespoke interface. SAP targeted OutlookSoft over other, larger vendors in 2007 with the intention of migrating the underlying components that OutlookSoft utilized to their equivalents in SAP’s NetWeaver platform. This migration would allow SAP to have an EPM tool that is fully compatible with NetWeaver. SAP now supports two editions of BPC, one for SQL Server and another for NetWeaver.
Statutory Consolidation
The first reporting cycle we will cover in this article is statutory consolidation, which is the process of producing a consolidated statement of financial position, a consolidated statement of comprehensive income, a consolidated statement of cash flows plus any accompanying disclosures in compliance with the GAAP requirements under which a corporation may publish their results.
To be clear, both tools are more than capable of handling the vast majority of aspects that are necessary for a consolidation tool such as translating multiple currencies, consolidating global or equity methods entities, minority interest calculations and the elimination of intercompany, reciprocal transactions. However, this article focuses on the distinctions between these two tools, so we will not review how they both process a consolidation (actually an entire article could be written just on this point alone).
One of the major aspects of consideration is the behavior of the data entry environments for these two tools, which serves as the basis for a consolidation. Both tools support multi-dimensional analysis wherein several of dimensions can be created in a dimension library and then utilized to form a cube to which data is entered. These cubes then support analysis such as a P&L detailed by product and then by region or a balance sheet which is analyzed by account movements.
However, the two data entry environments differ in behavior, in that for BPC, all individual dimension member crossings are available for input while in BFC each specific data entry point must be explicitly opened during the development phase. To illustrate this point in BPC, if the product dimension is added to the data entry environment or cube so that the income statement is analyzed by product, all accounts in this data model can now be analyzed by the product dimension -including the balance sheet accounts- which may not be appropriate.
It is possible to block certain types of analysis in BPC, but this data validation is either at the report level or filtered out via custom ABAP coding for the NetWeaver edition. This data validation can then be applied to data entry, journal entries and data imports.
However, this custom ABAP development can only have one driver dimension to identify valid data points. So for example, the account dimension can be used to identify valid intersections of accounts and account movements, but it is not possible to identify valid accounts, account movements and a user defined dimension such as products.
To perform this type of data validation in the Microsoft edition, a custom stored procedure would be necessary. Either way this restriction in not inherent in the structure in the application.
BFC has the opposite behavior; all intersecting data points are blocked for data entry or importation by default. During the implementation, the development team must then open each individual data point or ranges of data points. The screen shot below displays all valid and invalid data entry cells for BFC. The yellow squares indicate the valid account and movement combinations.
Figure 1: SAP BFC Category Builder Flow Behavior
click to enlarge
The important question to ask is why it would be desirable to have one behavior versus another.
If you are performing a large scale consolidation with multiple data sources that are heterogeneous in nature, it would be advantageous to have a very tight control over the data entry environment. If the consolidation is smaller in nature or there is a more homogeneous data source, say a single datawarehouse hosted by SAP BW, the additional overhead related to development time of restricting or opening each data point would not be necessary. The tipping point between favoring one method over another may also depend on your consolidation team’s time and ability to check the data submitted to the consolidation.
Another differentiator between the two tools is the business logic, which is employed to process the consolidation. SAP BFC natively supports the elimination of inter-segment trading within a single legal entity that has multiple business segments. Again, this is a feature intended to support only the largest, most complex consolidations.
SAP BPC does support the consolidation of multiple segments, but only between legal entities not within them. To perform this type of elimination in BPC, it is possible to collect data at a lower level than legal entities such as business unit or segment. However, when the choice is made to collect data at a level lower than the legal entity, other issues arise in the consolidation process such as the allocation of goodwill or purchased intangible assets to a specific operating segment instead of the purchasing legal entity.
Furthermore, it must be noted that there is a very negative aspect regarding how the consolidation rules are built and function for BFC. Each rule supports only a specific journal entry opposed to a series of journal entries in SAP BPC; consequently, the number of rules can be very high depending on the scope of the project. Consequently, it can very difficult to maintain a consolidation in BFC without outside expertise or an in house team that is very knowledgeable of the tool.
Included in the acquisition of BusinessObjects is another tool supporting consolidation processes, InterCompany Server from Cartesis, now re-branded to SAP Intercompany.
This tool is designed to facilitate the reconciliation of intercompany data by providing an interface where users can match intercompany trades prior to submitting data to the Group’s consolidation tool. Intercompany reconciliations can be performed at either account level or the invoice level. Reconciliations can also be performed in the currency of the transaction. An added benefit of this tool, is that the reconciliation process can start on say, work day minus two or three as opposed to the start of the submission process on the first working day of the month, which would allow more time for the reconciliation process and therefore facilitate a fast close process.
The licensing of SAP Intercompany has been bundled with the purchase of either BPC or BFC, and it can be used with either tool.
Since SAP Intercompany was originally a tool provided by Cartesis, the user community of BFC is more accustomed to using this tool in conjunction with this product. For certain BPC clients the usage of Intercompany would be advantageous, but due to BPC’s added flexibility it is not necessary to utilize an additional tool for reconciling transactions in their document currency. An additional cube or model, which is analyzed by transaction currency, can be created in BPC to support this process. Conversely, to reconcile intercompany transactions at the transaction level and in the currency of the transaction, it is necessary to use SAP Intercompany.
As for manual journal entries, both tools also provide a facility for posting manual adjustments; just as all tools that support consolidation must provide this functionality. BPC’s interface can be seen below in the following print screen. Data entry into this facility is straight forward. Furthermore, the header of the journal entry is highly customizable.
Figure 2: SAP BPC User interface for posting manual adjustments
click to enlarge
In contrast to this interface, BFC’s has a more complicated data entry screen. Instead of a tabular format which is intuitive to an end user, there are two entry levels: one for the account and flow combination and another for the analysis of those accounts and flows, which makes it rather difficult to enter amounts. It is also not possible to copy and paste amount from MS Excel. Below is a print screen of a journal entry in BFC.
Figure 3: SAP BFC User interface for posting manual adjustments
click to enlarge
However, in SAP BFC all journal entry data is analyzed by a specific dimension dedicated to tracking journals, called journal entry number. Consequently, reports can be built that retrieve the detail of a specific amount by journal entry header. This type of report is extremely useful in determining how an amount is built up from the input level to the consolidated position; especially if multiple manual journal entries have been posted to the same account. The following print screen from BFC displays this type of analysis. It shows all manual and automatic consolidation entries for a specified amount. This report cannot be built in BPC within custom development.
Figure 4: SAP BFC Journal entry reporting
click to enlarge
In BPC this dimension is not present by default; consequently, to develop a report by journal entry header an equivalent dimension must be added along with accompanying functionality that links the dimension members to the journals that is inherent to BFC. Depending on the customization of BPC, this type of reporting would generally require a dedicated model to support this functionality.
Summary: Again BFC was developed with the intention of supporting a consolidation for a large scale multinational corporations, hence the need to ensure a high degree of data quality or support for multi-segment requirements. On the other hand, BPC is more of a general and flexible EPM tool. It is capable of supporting the requirements for the vast major of listed companies. For example, it is flexible enough to support intercompany reconciliations in transaction currency. As per the following sections of this article, this flexibility will also show that BPC is capable of supporting a wide range of other reporting initiatives.
Budgeting, planning and costing
The reporting cycles of budgeting, planning and cost allocations, such as activity based costing, have been grouped into one section within this article because these processes leverage much of the same functionality for data modeling.
A major aspect of data modeling is related to allocations that are driven by financial indicators to support budgetary or costing requirements. These allocation can be either top down or activity based in nature. BPC utilizes a scripting language which is more than capable of handling these requirements; conversely, there is no native functionality in BFC that can support this type of data allocation.
SAP BFC can support the collection of budgetary or planning data to produce a consolidated budget or strategic plan, but if an implementation requires the modeling of data, BPC is the only possible option of the two. In general, BPC is able to support a wide range of business requirements via its native scripting language that can support a number of conditional and data manipulation statements.
A specific aspect of SAP BPC’s scripting language is the ALLOCATION function, which is able to support the core aspects top down or a driver based data allocation necessary for budget modeling or cost allocations. Rules in BFC, whether they are consolidation, pre-consolidated or package rules can only perform a simple insertion and selection of data unless SQL is added to augment this functionality.
Summary: Although an important section, this is actually a rather short because the options are clear. If a client intends to only collect budgetary or planning data in their EPM tool for displaying actuals versus budget or plan, BPC or BFC are both able to handle this requirement. However, if data modeling is necessary to construct the budget or plan, or it is necessary to generating a costing model, SAP BPC is the only option.
Industry specific and non-standard reporting cycles
Depending upon the industry of a company, the finance department may be required to undertake additional reporting requirements other than the principle reporting cycles of actuals, budgeting, forecasting and planning.
For compliance purposes, banks are required to provide additional information for FINREP and COREP in Europe or Solvency II compliance for insurance institutions. As for other internal controlling requirements, a company in a capital intensive industry may wish to further analyze their CAPEX expenditure via their EPM tool. Furthermore, it may be necessary for the finance department to undertake requirements that go beyond the standard domain of the finance function such as sustainability reporting.
Both of these applications are able to store and report on multiple work streams within a single database. A single database is advantageous if specific amounts should tie-out between the various work streams.
Both applications are also able to create and store a high level of dimensionality. A single BFC instance can create and store up to 18 user defined dimensions while BPC can create and store approximately 20 user defined dimensions. These user defined dimensions can be applied to specific reporting work streams within a single instance of the application. So if additional analysis is required for more detail, additional dimensions can be added as necessary. Consequently, if the actuals and budget work streams analyze the data in a specific manner, this dimensionality can either be reduced or augmented for the needs of the additional reporting work stream.
The act of building these various types of analyses are actually very similar between these two products. The dimensions that are used to analyze data are created and maintained in a dimension repository or library. Once created they are applied to an individual analysis cube. This analysis cube in SAP BPC is called a model while in BFC it is called a category scenario.
Once the dimensions have been applied to the model or category scenario, functionality such as formulas for various calculations, data validation controls and other aspects are then added. Once all of the functionality has been applied, it is deployed for data collection. Reports are then built to input to or retrieve data from these models or category scenarios. The interesting aspect is that multiple models or category scenarios can be created within an individual database, each with a specific set of dimensionality that is necessary to support the requirements of a given work stream. The data within these work streams can then tie back to each other via data validation controls that cross check amounts between the work streams.
The major point of difference relates to the calculation of any necessary ratios that may be required. Both tools can calculate ratios or KPIs on the face of a report, but if it is necessary to store these amounts in the database, BPC’s scripting language is a major advantage over BFC. Several reasons why it may be necessary to store KPIs in the database would be for consistency purposes (calculated once and re-used in multiple reports) or archiving may be necessary if a KPI is objectivized.
Furthermore, a complex calculation may require multiple steps wherein a simple formula is insufficient. The calculation of a DSO or a DPO would fall under this category. Due to BPC’ native scripting language, calculating ratios or KPIs is less complex than in BFC. In BFC, it is necessary to enter SQL directly into the application via a SQL rule or with the usage of functions and coefficients that also contain custom SQL.
Summary: Both SAP BPC and BFC are very capable of handling multiple reporting cycles due to the high level of dimensionality that can be created in the respective applications. Regarding the calculation of KPIs, BPC does provide and edge over BFC due to its native scripting language. BPC’s data validations are however new to version 10 and are only available for the NetWeaver edition.
In contrast, BFC’s data controlling functionality is twelve plus years old. With this maturity, it can perform very sophisticated data validation checks between reporting cycles plus as per the consolidation section of this article, it provides a tighter control of the data entry environment. Although reviewing additional third party tools is outside the scope of this article, it must be stated that both applications within SAP’s EPM offer are much more capable than their peers at supporting several reporting cycles with differing analysis. For example, Cognos Controller can only support four user defined dimensions and either four to seven, depending on the version, for Oracle HFM.
Integration with overall IT landscape and scalability of the application
A major consideration during the selection process for an application is how that perspective tool fits into the existing ecosystem of platforms and applications that are currently in use by the finance department. This section attempts to describe the architectures of both of these tools, how they can be integrated with the overall IT landscape and how they could potentially scale up over time to meet the needs of the finance department.
As described at the beginning of this article, OutlookSoft based a significant proportion its functionality on SQL Server’s components such as SSIS for running batch processes such as a consolidation or SSAS for dimension member aggregations and dimension member formulas.
Since SAP’s acquisition of OutlookSoft, SAP has migrated these underlying components to their equivalents in the NetWeaver platform. Consequently, SAP now offers two editions of BPC; one for SAP’s NetWeaver platform and another for Microsoft’s SQL Server.
For an organization or company that has made prior investments in SAP BW, the possibility to have an EPM tool that is highly integrated with its source systems is extremely appealing. By using the same underlying technology as its source systems, the NetWeaver edition of BPC acts as an additional module of SAP BW.
As an additional module, SAP BPC can be configured to access user defined Business Add-Ins (BAdIs) within NetWeaver to enhance the functionality of the application. Furthermore, drilldowns can be configured within BPC, which allows a user to drill from a report within BPC down to its source BW. SAP has also made significant investments in SAP HANA, an in-memory database for NetWeaver, which has the potential to have significant performance increases over traditional relational databases, which might be useful for scaling driver-based planning applications.
Actually, an individual insight could be written specifically on the subject of SAP HANA and how it effects performance of applications that sit on top of it, so we will not delve into specific in this article, but this evolution in data storage should have a huge impact on performance of BPC. The following is a schema of BPC.
Figure 5: SAP BFC architecture schema
SAP BFC has not been integrated with SAP’s NetWeaver platform, and at the current time, it remains to be seen if it ever will be. BFC does have the ability to utilize the leading relational databases on the market today, Microsoft SQL Server and Oracle Database for the data storage tier of the application; no specific edition is required for connectivity to either database.
SAP BFC is a multi-tier application with the aforementioned database tier, an application server tier and a thick client or web client. The application tier is an in-memory service to which end-users connect. During ongoing activity, objects within the application are stored in this tier aside from the financial data. The main advantage of this multi-tiered architecture is that BFC can be configured to generate and manage several instances of a given database. For example, if multiple instances of this service are utilized, they can be started on multiple servers.
Furthermore, as additional users connect to the application, additional services can be spawned. Recycling of services can also be established. So for example, as a service hits a certain defined memory limitation, connectivity to this instance is closed for additional logins. A new service is then spawned by the application, with the additional logins directed to the new service. Once all users have logged off the closed service, the service is then stopped. The following is a schema of BFC. It shows integration of SAP Intercompany and SAP Financial information Management (see next paragraph), which may be typical for an installation of BFC.
Figure 6: SAP BPC architecture schema
SAP has also made significant investments in the development and integration of Financial Information Management (FIM) for its EPM tools. FIM is an ETL system that can be utilized with any of SAP's EPM tools. FIM provides the standard functionality of data extraction from multiple systems, data mapping via transformation and uploading into one or multiple SAP EPM tools. FIM can also be used to perform integration between multiple EPM tools as well.
The major attraction of the application of FIM is that it enables a user to drill from an amount within a report of an EPM tool to the source data that has been loaded into the FIM server. Consequently, the user is able to view the composition of every amount loaded into the EPM tool prior to data mapping and transformations. This process is called drilling to source.
FIM also displays a history of each data record loaded into the target EPM tool. Furthermore, if SAP ECC is utilized, FIM can be further configured to drill from FIM directly to the data in ECC. This process is called drilling to origin. However, it must be noted that drilling to origin within ECC requires specialized knowledge of FIM and ECC.
Since SAP BPC utilizes Microsoft SSIS or SAP BW process chains, it is possible to develop a sophisticated integration layer without FIM. The major attraction for a BPC installation would be the drilling to source and drilling to origin capabilities that FIM provides for every amount loaded into the application.
In general, SAP FIM is much more interesting for a SAP BFC implementation. Prior to the integration of FIM, the only ETL option within BFC was a module called Datalink. This module is capable of performing very complex data transformations, but it is not able to extract or load data.
Basically it provides only the "T” in ETL. Consequently, the combination of FIM with BFC, is the only real option that SAP provides to support complex data integration requirements for a BFC implementation. The downside with FIM is that it requires additional components and integration between these components, but like SAP Intercompany, the licensing for FIM has been bundled together with BFC (licensing for FIM has been bundled together with either BPC or BFC).
Summary: SAP BPC NetWeaver edition does appear to be a natural extension of a company’s data warehouse or general ledger if the client already employs a NetWeaver environment.
The ability to leverage functionality within NetWeaver from BPC is very intriguing in terms of data integration, auditability or custom-built calculations. As for BPC’s SQL Server edition, it still utilizes SQL Server’s components, so by default, BPC provides a high level of integration without an additional tool.
Regarding SAP BFC integration capabilities, without the implementation of FIM, clients will struggle to provide an integration layer that is sufficient unless a third party ETL is used. As an aside, it is very curious that BFC’s original software vendor Cartesis never provided a true ETL layer either within the application or via a reselling agreement; especially considering that BFC’s original target market was large multinational corporations on the CAC-40, which are the very clients that would require this type of functionality.
Workflow and Analysis
Workflow is the sequence of events or processes through which the submission of data passes from initiation to completion. Within SAP BPC it is possible to create and support a custom workflow, which allows an administrator to monitor the submission of data through a structured sequence of steps for a given reporting cycle.
This apparatus is called a Business Process Flow (BPF). BPFs are a truly admirable idea for ensuring that end-users submit data in a structured manner. This is especially necessary for a complex submission of data such as an activity based budget that may require several iterations of submission. SAP has greatly enhanced BPFs for version 10 as well; however, this functionality is still generally a difficult feature to implement.
To be effectively used, a company would require dedicated resources to build, administrate and monitor the user-base through the BPF. A high level of granularity within a BPF process is also required to ensure that entities do not block one another through a reporting cycle.
BFC does not provide an equivalent feature. Data submitted to BFC must follow a pre-defined process of data entered into data entry environment of BFC known as the package layer.
Once data is submitted to a package, the data is validated, published and integrated. Publishing a package is the equivalent of stating that the data within it is now available for review. Integration copies the submitted data to the pre-consolidated level of the application where journals may be posted against it and the consolidation engine can then select these amounts for processing. If an amount is not integrated, it will not be selected by the consolidation. There is no deviation from this submission process.
Furthermore, the ability to support a phased submission is also highly desirable. A phased submission is the ability to close off or lock specific data points during a submission process. For example, the entire chart of accounts would be open for the submission of actuals on working day one, but at the start of working day two the sales line is locked, then the entire gross profit is locked down by the end of working day three, and so on until the submission is complete. This process ensures that a flash report which is disseminated at the start of a reporting cycle, ties to the final reports which are distributed and the end of the close. Both tools have potential to lock sections of the chart of accounts, which can be utilized to support this reporting aspect.
As for reporting and analysis, SAP’s EPM version 10 tools actually use the same reporting tool, the EPM add-in for Microsoft Excel. In fact, all of SAP’s EPM offer including Profitability and Cost Management and Disclosure Management all use the same EPM add-in reporting tool. This add-in is a menu driven reporting tool; no specific scripting language is required for its implementation.
Reports built by this tool can provide various hierarchical and drilling analysis, features related to dash boarding such as stop lighting may also be implemented. For functionality specific to statutory consolidation such as flow analysis reports, these report can also be can be configured and built. For budgeting purposes, spreading and trend analysis reports can be created.
SAP's EPM add-in for Microsoft Excel is natively a part of BPC’s architecture; however, BFC requires an additional implementation of BusinessObjects Extended Analytics. The EPM add-in requires an OLAP cube for storage and data processing, which is not inherent in BFC’s architecture.
Consequently, Extended Analytics plus the accompanying infrastructure for web services and OLAP is necessary. Furthermore, usage of Extended Analytics has a design impact on BFC because it is possible to introduce sparsity (null values) into the analysis of user defined dimensions. For example, when analyzing the chart of accounts by product, it is possible to have null values for the product dimension for the balance sheet accounts while the statement of profit and loss is analyzed with specific values.
When implementing Extended Analytics all dimensions must be populated with a value for all records. Furthermore, BusinessObjects Extended Analytics is available in Microsoft Analysis Services and SAP BW flavors. The BW version can be interesting for SAP BW customers, but its uptake has been rather low and the product is not the most mature within SAP’s EPM stack. Compared to BPC, it is another level of complexity as the OLAP cubes are inherent to BPC and do not require an additional setup, comparable to integrating Intercompany or FIM as explained earlier in the consolidation section of this document.
If BusinessObjects Extended Analytics is not implemented, the EPM add-In cannot be used. SAP BFC does offer integrated reports, but they are static in nature and do not provide the same degree of functionality for ad-hoc reporting that is common place for many user basis.
Summary: In terms of workflow, SAP BPC does provide an alternative to many EPM tools on the market today with its Business Process Flows. For larger companies that devote the resources specifically to this functionality, they can be a very potent tool for ensuring a higher data quality than a straightforward submission process based more on manuals and on-screen aids.
Consequently, SAP BPC does have a unique advantage in the EPM market regarding this aspect. In terms of reporting, the same EPM reporting tool is actually the identical technology, which can be very interesting for a client that is employing multiple tools within the SAP EPM suite of tools; however, BPC has the added advantage this reporting tool is natively integrated with it while BFC requires the additional implementation of Extended Analytics.
Summary of why a company would invest in one of these tools
As per OutlookSoft’s original intention, BPC was originally designed as general tool for the finance function, capable of supporting a wide range of reporting initiatives.
As per each section in this article, SAP BPC has either solid or above average level functionality. None of the sections in this document require additional tools to meet the needs of a specific reporting aspect. BPC is also the clear option between the two tools for budget modeling or cost allocation projects. With the leverage of HANA and the close integration with IP functionality for the embedded version of SAP BPC on NetWeaver (version 10.1), SAP takes the BPC platform to the next level, allowing in-memory technology and a wider range of planning functionality. Also good to know is that SAP commits to further develop BPC for the Microsoft platform, as the focus in the past for BPC has been the integration on the NetWeaver platform.
BFC has however evolved as a specialized tool for statutory consolidations. Prior to SAP's acquisition of the tool, it was already known for being very proficient in statutory consolidation, but since the acquisition by SAP, the enhancements to the data integration layer of the application make the tool much more suitable to its original target market, large multinational corporations such as those listed on the Euro Stoxx 50 or the FTSEurofirst 100 Index.
