BOFC: Slow performance via excel link

Question

Hi!
I am trying to gain some insight into why the company i work with´s BOFC implementation is performing poorly.
Both data input and report generation is suffering, with relatively simple reports using pivot-cubes taking 30-45 minutes.
At worst it can take up to two hours to upload new data.
Web interface is not having any issues.
I realize this is not much to go on, but in general, do you guys have any input for best practise for the following points:
Data archiving: There has been no archiving of data since 2004. Is it best practise to do this after yearly conso? Is it known to create performance problems if you don´t? Consolidation is for roughly 200 accounts, and db is in the hundreds of gb. Solution did perform better in 2004-6 with smaller dataset.
Reporting: How widely is BOFC excel link used as a reporting tool for controllers? I am unsure if this is the best way to access the data, especially given the freedom you give the user as to how to build your queries. (ie searching everything to find one accounts monthly etc.)
Any help or pointers as to where to look would be appreciated!
I am doing this from a general APM perspective, and not as BOFC expert.
Edited by: jonkanon80 on Dec 14, 2010 2:33 PM
Edited by: jonkanon80 on Dec 14, 2010 2:34 PM

Answer 1

Forget the unfair comparisons to excel, numbers can't even keep up with AppleWorks!
I have a spreadsheet in Apple Works that I use to track revenue and profit for my business. I enter two numbers per day: Total Sales and Total Profit. There are 6 calculation columns that display 7 and 28 day running averages for sales, profit and margin each day. The spread sheet is about 1400 rows (one row per day). No special formatting, no formulas more complicated than if(), sum() and average().
In Appleworks:
Data entry: instant - as fast as I can type.
Create a line chart on 6 columns and 1400 rows: 5 seconds
Memory usage: 11 MB
In Numbers:
Data entry time: Spinning beachball for ~10 minutes after each keypress (yes, REALLY)
Create chart: Unknown, maybe not possible. (Still waiting after 1 hour of spinning beach ball and 100% processor usage)
Memory usage: 1009MB (yes, ONE GIG), plus 2GB VM file (!!!).
I mean, how sad - ONE HUNDRED times more memory usage and over ONE HUNDRED tomes SLOWER. Absolutely terrible. If I were the engineer on this project I would be absolutely ashamed of the performance.