Lessons Learnt: Technical Restrictions in SEM-BCS in a Very Large Implementation Project

[Former Member]

There are three SAP applications dedicated to financial consolidation.

SEM-BCS still has the richest and deepest functionality which is still developed and delivered in Enhancement Packages.

However, it is positioned more as application for the biggest companies. And there are not many left which have no consolidation application.

I want to tell you about one of the last very big SEM-BCS projects. 

I do not afraid to call this project as the most unique one. Because of its scope, very rigid Client’s requirements, and technical restrictions of SEM-BCS (due to conformation to these requirements) that nobody met before.

So, the client is one of the world’s economical giant. I was invited by a General Contractor (hereinafter GenC) as a subcontractor and later I came to the project again, this time conducting the project’s Quality Assurance, on behalf of SAP. So, it was very interesting having vision of the project from inside to look at the project architecture from the outside.

The key features / requirements of the project:

1. The main goal of the project was Financial Consolidation reporting according to National standards and IFRS, with all disclosures, including the Segment Information and Reporting.
2. Requrement to automate the entire accounting consolidation job, including calculations of all transformation adjustments (Local – National – IFRS).
3. Number of Consolidation Units (CU) - several hundreds initially.
4. Most of CUs provided their financial statements in the form of ACCESS reports, with absence of the common Chart of Accounts and with different precision (units – thouthands – millions).
5. Reporting must be made in Millions (without decimals).
6. Presence of multiple breakdowns from different reports for total figures.

              For example, the A/R value has the following breakdowns:  

      - by the partners;

      - by the age of indoubtedness;

      - by the kind of  indoubtedness (trading, for sale of Fixed Assets etc.);

      - by the geographical market of the debtor.

7. NO ERRORS due to rounding is allowed (it means the FULL consistency of ALL reports is a must).

So, what’s unusual, aggravating, in this reqirements?

1. Segment Information and Reporting. Segmentation usually means allocation of the total figures among segments according to some rules. Due to sometimes very complicated rules the realization of this requrement lead to creation of several hundreds of usual SEM-BCS allocation and reclassification tasks, upto 100 BadIs and upto 100 BI-IP planning sequencies, sometimes with custom functions. 
2. Transformation adjustments are usually calculated outside the consolidation system since very often such calculations require practically transactional data. The necessity to have such data (plus separate data for segments) complicated the data model very much (upto 7 special infocubes in BW). Realizations of this requirement also lead to creation of several hundreds of allocation and reclassification tasks, BadIs and BI-IP planning sequencies.
3. Number of Consolidation Units refelects the giant scope of the holding.
4. Absence of the common Chart of Accounts, different reporting forms, different precision of data – necessity to bring all the data to the same precision.
5. Reporting must be made in Millions (without decimals).
6. Presence of multiple breakdowns from different reports for total figures (and totals themselves). It would be logical to have in the system only breakdowns which being summed up give the totals. However, denomination of different breakdowns to Millions (without decimals) may lead to different totals.

An example. The breakdown A (in thousands): 490, 490, 490, 490, 490, 490, 490, 490, 490, 490

(10 times by 490 thousand).

The breakdown B (in thousands): 1200, 1200, 1200, 1200, 100.

The sum of denominated by 1000 data of the breakdown A gives 0. (We called this case as data degeneration).

The sum of denominated by 1000 data of the breakdown B gives 5.

Which one is true?

The correct amounts are present in the system as totals figures (along with their breakdowns).

7. NO allowances due to rounding.

Even in the systems which use data with the same precision might occur difference in 0.01 due to rounding after Currency Translation. Here, additionally to usual difference we might have data degeneration in the breakdowns due to denomination to Millions without decimials.

In general, requirements #5, 6 and 7, almost inevitably must destroy the mutual consistency of most of reports (as well as equivalence of the total figure and the sum of its breakdowns).

What were the solutions and which restrictions met?

In order to allow the system to align all the figures with Millions without decimals the Group Currency was created as a new currency code with zero decimals.

The idea – in a precalculation cube (with usual GC with 2 decimals) we bring all amounts to Millions (denomination), then restore data consistency between breakdowns and totals by attributing the diference between the breakdowns and the total to the determined accounts (that of course lead to significant increasing in their number), then restore data consistency among the reports.

After that we reloaded data into BCS cube with Millions without decimals and after execution of the most tasks data would remain consistent in Millions without decimals. Exceptions – are allocations. They may lead to data degeneration.

In general, such restoration of consistency was made on each step of the process:

• after the initial denomination of Local data;
• after Currency Translation;
• after Calculation of Segment Information and Segment Reporting.

Because the number of FS items where the differences were attributed to was large, the C/T steps were configured for small groups of items. And here we met

Restriction #1 – number of steps in the C/T method should not exceed 999! (Though, it’s true for other methods too)

The solution for such a situation is to decrease number of steps below the limit by decreasing the number of FS items or rules of their C/T.

The very large amount of tasks brought several restrictions.

Restriction #2 – performance of loading the consolidation monitor (several hours)

and

Restriction #3 – number of tasks in the consolidation monitor should not exceed 999!

and

Restriction #4 – number of columns in the consolidation monitor should not exceed 255!

The 2nd restriction was overcame by the SAP Support by eliminating the bugs in a code. Performance was enhanced drastically, but anyway became rather annoying.

The 3rd restriction was overcame by a dividing of consolidation area into several ones with their own monitors.

The 4th restriction was overcame initially very simply: just by placing the ConsUnits into columns and Tasks into rows. But when the number of ConsUnits increased we met

Restriction #5 – it’s impossible to load the consolidation monitor if you have both, the number of ConsUnits and Tasks exceeding 255 (as a consequence of restriction # 4)

The remedy here is to decrease either the number of ConsUnit to be consolidated or number of tasks in the same Consolidation Area.

The Support guys from Waldforf were very surpised that GenC complained about such restrictions that were not met before by anybody else (though it was not said so, but the reaction was – you are crazy!).

The estimated during QA time of 1-time running of all tasks gave about 10 days that is hardly acceptable if to take into account possible need to make several iterations.

Recently I talked to one of the key persons of GenC and asked about the fate of the project. The asnwer was: the key users sabotage the system because it takes for them less time to consolidate as before, without SEM-BCS.

So, here I wanted to tell about this project experience, what SEM-BCS may and what – not.

It’s also a bright example what may happen with implementation project if to agree on and conform to ALL the requirements of the Client.