We need use of multi-dimensional analysis tools, and are being pushed
towards Hyperion Essbase by our home-office IT staff. I have started
looking into the tools and have some reservations as to whether
Essbase is the right tool for us. Please advise if you can.

We are a mid-sized, wholly owned subsidiary of a very large company
(our owner is on par with GE).

We need a tool to use at our site, not to be used by the home office.
We don't deal with multiple currencies. We don't deal with
consolidations. We do populate a financial template, which is
uploaded the home-office consolidation/ financial reporting tool.

We primarily need a system for financial analysis and reporting.
There is also a need to operational analysis. Financially with have
the standard dimensions (year/qtr/month, scenario, account, cost
center, etc.) and also about a half dozen other dimensions. (maybe 10
in total).

Our financial and operational data resides in MS SQL 2000 relational
databases (we are tracking roughly 500,000 transactions a year). Our
business is constantly changing, and operational metrics regularly
change as well. We have roughly 5-10 users who need direct access to
our OLAP database. Our data tends to be very sparse.

There is another division in our company that used TM1 a long time
ago, and has migrated to Essbase 6.1. The current plan is that we can
utilize the Essbase implementation at this other site. We will
develop our own cube structure, and push our data to the other site
over our WAN. The only Essbase components available are the basic
Application Manager and Excel Add-in tool. Our business model is
completely different than other division, fwiw.

I have a little experience playing with MS Analysis Services, and as I
study the 1500+ page Essbase administrator's guide (Vol 1), I am
noticing Essbase seems a lot harder to deal with than MSAS. Example:
Integrating our source data to Essbase, maintaining the data import
Xrefs, building the initial structure, and user security all seem more
cumbersome. Maybe if we had budget to buy several other Hyperion
tools this wouldn't be the case.

I've also noticed that the Essbase excel add-in doesn't seem as
flexible as some of our users were hoping. Many of our users have
previous experience with Hyperion Enterprise's "Retrieve" excel add-in
and were quite happy with it. I don't see the same ability in the
Essbase add-in (referencing back-end OLAP data via a formula within
an individual cell).

The initial costs of Essbase won't be that high for us, but we are
still budgeting ten's of thousands for consulting fees to help get our
cube structures setup. Since we already own MS Analysis Services, and
our Financial SQL Server box is more than robust enough to handle
additional workload, it seems to me we might be heading the wrong
direction.

If I start pushing that we should consider MS Analysis services,
coupled with one of the popular excel add-ins it will, at a minimum,
delay our Essbase implementation. I am an experienced accountant and
database developer; I feel I could develop the OLAP structure on my
own using MS Analysis services and save the company money, maybe
providing a better solution.

I don't want to "make waves" unless I feel strongly that I am right.
What do you guys think? Btw, I tried to get the company to subscribe
to the OLAP report but that idea didn't fly.

Thanks for any advice you can offer.

wwestrope (AT) flexjet (DOT) com (Wayne W) wrote in message news:<f31856eb.0310090732.5ebe56e0 (AT) posting (DOT) google.com>...
Suggest you take a look at a product called TM1. Its primary virtues
are: Its a pure MOLAP solution. Very easy to install and maintain.
Requires very low level of support or involvement by IT personnel.
Very high speed for updating cubes and data with multiple interactive
readers and writers. It has many front-ends. Most are Excel based, so
they are very comfortable for finance personnel. Its limitations: Its
frontends are not as complete for rote reporting. Not suitable for
very large databases (>64GB). Its a pure MOLAP solution.

Up-front caveat: Though I have a long history with Essbase, my focus as a
practitioner for past few years is Analysis Services (AS). My Essbase
knowledge is dated; this is an attempt at honest feedback.

The reason I switched my professional focus from Essbase to Analysis
Services is because Essbase drove me nuts. It was buggy, the APIs were
weird, care and feeding was a joke (especially the requirement that every
member in a cube have a unique name). Even in the days when I made my living
from Essbase, including speaking at their annual conference, I never once
recommended it, publicly or privately.

The advantages of AS are numerous, not the least of which is AS is thriving
and improving; Essbase has more or less withered on the vine since the
Hyperion acquisition.

Big picture, in my view, there are three valid reasons for an organization
to choose Essbase:

1) Multi-platform
2) Used in conjunction with other Hyperion products
3) Faster calculations (AS calculation model is strictly runtime, calc
results aren't persisted, calc-intensive models are slow)

I did a comparison on behalf of a client last year; ping me if you'd like a
copy.

tom @ the domain below
www.tomchester.net


"Wayne W" <wwestrope (AT) flexjet (DOT) com> wrote

Essbase - Analysis Service comparison response to news group
comp.databases.olap



Well... a long question deserves a long response...

I read your note and the response from Tom Chester. I have visited Tom's
site in the past and have taken a look at some of the samples and
information and appreciate his insight into Analysis Services. However, I
have a very different perspective on your question from my experience.



First of all, my caveat is that I have worked with Essbase for more than
eight years and was thrice certified on it - including as an instructor. On
the other hand, I have recently worked a lot more with Analysis Service
including OLAP consulting and co-writing some related software with the
Microsoft BI group in Seattle. Note the main reason for my change in focus
is that AS is in a growth mode due to price (free with SQL Server) and the
fact that it is Microsoft - not because it is better overall than Essbase -
....yet.



AS2000 has a long way to go before it can really be genuinely compared to
Essbase. Any comparison now that suggest that it does everything that
Essbase does is correct only in that if you know how to program, it can
appear to have all of the same features and, of course, some good things
(e.g. local cube capability) that Essbase does not have. But to really make
my point even C++ can do anything that Essbase does - but you have to do a
LOT more low level programming. However, like any competitive product
comparison, the answer is not that one is always better, the answer mainly
depends on what you need it for and whom you need it for.



Essbase is a mature and stable product but like all software, it has bugs in
its newer features. It is much simpler to use for most OLAP applications.
This is because it has a lot of common business rules built in, for example:
Expense Reporting, Time Balancing, and Alternate Rollups (implemented in a
much simpler way than hierarchies in AS). Business Analysts that I have
taught have created real Essbase databases from scratch after one 4-5 day
course. On the other hand, one has to be very technical and quite
comfortable with relational databases and SQL and for that matter MDX to
create similar AS cubes. Essbase's Application Manager makes the concept of
multidimensionality much more obvious than Analysis Manager.



Note that AS is full of bugs and OLAP oversights as well. For example a bug
that I ran into recently is that you can't do a write-back to an AS cube
sourced from SQL Server if a hierarchy contains disabled lower levels -
which is very desirable in a budgeting (hence write-back) cube. The exact
same thing works with MS Access as the source - not that that is a viable
work around. An oversight example is that if you have multiple hierarchies
based on different properties (columns) of a source dimension table (a very
useful thing), then you can't write plan data to that cube without
specifying the bottom level of all of the hierarchies when in fact, just
specifying a bottom level base dimension member should be sufficient since
it determines the other properties - this exposes the model like a
de-normalized relational table which can get out of sync.



As for the Essbase Excel Add-in. You may be an Excel expert that loves
having direct formulas linked to the database, but most business users, once
they see it, much prefer the Essbase "query by example" add-in - where what
you lay out is what you get. This retrieval method may force the user to
stage the data before combining it on a single report or graph but because
of that, it is much easier to audit. After all, if you could create direct
links to relational database tables using some kind of huge Excel formula to
specify a single row and column in a table or view, would you really use
that instead of staging the data on a worksheet using MSQuery or some other
SQL import tool and then just referencing the data that you need?



I don't mean to bash Analysis Services, but since Tom defended it so much, I
thought that it deserved some representation. Essbase is a great OLAP tool
and does not need much in the way of enhancements which is why it has not
fundamentally changed much in five years except to try to become more
seamless with its relational sources. I could, however, also make a case
for Analysis Services if I knew the target audience and the application.



Hope this helps you.


"c-cubed" <ccervo (AT) bellatlantic (DOT) net> wrote

Fred,

Thank you for your comments. Such constructive feedback from the experienced
user will help us make Analysis Services better.
Couple of notes below

I have debugged through this scenario, and confirmed this bug. Please open a
case with PSS about it, such that we will be able to issue a hotfix which
addresses it.

The better way to model it in Analysis Services, is by using virtual
dimensions on such properties.
If you do it this way - then Analysis Services will know about 1 to many
relationship between the bottom level base dimension and virtual dimension
created off it, and then indeed during writeback, you will only be required
to position to the bottom level of the base dimension, but not of virtual
dimensions.

HTH,
Mosha

--
==================================================
Mosha Pasumansky - www.mosha.com/msolap
Development Lead in the Analysis Server team
All you need is love (John Lennon)
Disclaimer : This posting is provided "AS IS" with no warranties, and
confers no rights.
==================================================