|
Planning (Cognos) |
THIS PAGE REPRESENTS ONLY A VERY SHORT EXTRACT FROM THE FULL REVIEW.
TO VIEW THE FULL REVIEW YOU CAN PURCHASE THE REVIEW INDIVIDUALLY OR PURCHASE AN ANNUAL SUBSCRIPTION TO THE OLAP REPORT WHICH ALLOWS ACCESS TO ALL OLAP REPORT CONTENT.
Contributor uses an XML-based data structure within a relational database. Initial data is distributed to users' Web browsers in the form of fully calculated small cubes containing the data and rules relevant to them. This initial planning data may typically have been produced using a top-down approach using Analyst and transferred using a file transfer process while the historic actuals could be imported from operational systems.
This process of building Contributor data is carried out using Cognos Planning Contributor Administrator. A specified D-list found within Analyst is used to provide the breakdown by user class. This special dimension is called the E-list. Based on the rights assigned to each user class within the Contributor Administrator, each user gets their portion of the cubes downloaded to the browser. Text commentaries can be input and instructions can be displayed.
A workflow browser screen is first displayed showing the status of the various components of the plan, those responsible (owner) currently for their ‘slice’ of the plan, and where in the planning cycle the various planning slices are (not started, in progress, or submitted for review). This workflow screen can also provide guidelines to users regarding goals, considerations, etc. Additional commentary can be supplied with each of the cube slices accessed by the user. The users then select the slice of the plan they would like to access, and a new browser screen is displayed showing the various cubes in the plan.
Portions of the data can be made read-only for certain user groups: for example, actuals, targets and history can be grayed out. Data can now be secured via Access Tables within the Contributor Administration so only those areas of a dimension that a user should see can be set up.
The Contributor is able to re-execute the calculation rules on-the-fly so that users can see totals, weighted averages, etc as they enter data and it can be validated. Data can be entered at detail level as well as at summary levels. The ‘break-back’ feature is now available to allocate input data entered at summary levels (this feature has always been available in Analyst, but was absent in earlier releases of Contributor).
When a user has completed the data entry, the fully calculated cube is returned to the server, where the XML document is stored in the Contributor database. Users can update the local cube multiple times, during which time it is regarded as 'work in progress'. Once data has been submitted to the server, it is 'locked', and users cannot update it again unless their manager/reviewer rejects the submission. Managers can now alter or override users' submissions directly if they have ‘reviewer edit’ rights; originally, they had to log in as the budget holder to do this.
Consolidations are performed on the server, with fully calculated data again being stored in XML documents in the relational database. This data can then be viewed by managers. If required, data can now be moved back from a Contributor to an Analyst D-Cube via an Analyst D-link.
We were surprised to see that Adaytum chose to pre-calculate and store everything, as this is notoriously the way that multidimensional databases explode. Storing the data in XML documents in rows in a relational table is also likely to increase the space taken, compared to using an efficient multidimensional database. This combination of undesirable characteristics means that E-Cubes have probably the least efficient form of multidimensional data storage of any modern product. Cognos has responded to this criticism as follows: “This method of distributed processing provides for scalability within the Planning activity. It has the advantage of minimizing the server processing load because local client machines transmit fully calculated cubes back as single XML documents which the server merely has to insert into the SQL table. This allows the server to remain responsive even with a heavy concurrent user load.”
We think that the approach may work well enough as long as the cubes have relatively few, relatively small dimensions — no more than, say, five — with little sparsity. But as soon as the application grows, the system could soon get very unwieldy and inefficient. The recommended limit for the local cubes is 500,000 cells (and this must include both empty and calculated cells), though some customers exceed it and have several million cells per slice. The hierarchy dimension (the e.List) can probably handle several thousand nodes (though such large hierarchies would need small sub-cubes), so the maximum overall size for an E-Cube is perhaps a few hundreds of millions, fully exploded cells. This is small by OLAP database standards, but the inefficient database design would preclude larger sizes. However, for budgeting and planning applications, this size should be adequate, and as it is now easier to link multiple applications, should not inhibit deployments.
|
|
One issue for Cognos Contributor is that the mandatory use of relational database (SQL Server, Oracle, IBM DB2) and MTS means that Cognos Contributor cannot just be installed on end-user PCs and LAN file servers, as is possible with the legacy Analyst product. As such, it requires more IT support and co-operation, which makes software installation a longer, more complex task that can take days rather than hours. For sites with restrictions on table creation, it can also complicate the operation of the system. In addition, it means that Contributor must work with the particular version and service pack level of these servers that the site is running. The use of ActiveX controls may also offend the sensitivities of some IT staff, as this is a technology that is vulnerable to nefarious activities.
However, Cognos points out that once a Contributor application is implemented via Contributor Administrator, end users can start their planning activities without any IT involvement. The ActiveX component is downloaded once to each user from the server. When a user accesses a particular slice of the plan data, only that slice is transferred to the user’s browser. All subsequent processing is performed on the browser PC, with no server involvement at all. When the use enters data and presses the Enter key, it is used in the local application and is visible wherever it is used in calculations, but is not sent to the server (which is a significant difference from most Web-based planning applications). Only when users save or submit their data is the server involved with data transfer and processing.
Contributor now has three additional types of links for moving data between applications, in addition to the D-Links that are used to link cubes within an application:
 |
D-Links are used to move
data between cubes within a single application and are similar to those
in Analyst, except that in Contributor they work automatically, without
requiring the user to manually execute them. They can do this in two directions.
|
|
Administration links, added
in the 7.3 release, are used to copy data between Contributor
applications either on a scheduled or ad hoc basis. They are both
set up and run by administrators and use the Planning job system. They
can move data to both development and production applications and run
on the server. They allow matching between e.Lists and D-lists. |
|
System Links, added in the
7.3 release, are also used to copy data between Contributor applications,
from another server database to a local application. They are set up by
administrators, but are run by end-users on an ad hoc basis. For
example, an end-user may want to load a set of reference data from another
application to start a planning cycle. They can only be used with production
applications, and the eList must match to the eList in both applications. |
|
Local Links, added in the
7.2 release but renamed in the 7.3 release, are used to load data from
external sources or other Contributor tabs into local Contributor applications.
They are set up and run by end-users and run on an ad hoc basis.
External sources are Excel or ASCII files, so dimensions need to be mapped.
|
|
|
THIS PAGE REPRESENTS ONLY A VERY SHORT EXTRACT FROM THE FULL REVIEW.
TO VIEW THE FULL REVIEW YOU CAN PURCHASE THE REVIEW INDIVIDUALLY OR PURCHASE AN ANNUAL SUBSCRIPTION TO THE OLAP REPORT WHICH ALLOWS ACCESS TO ALL OLAP REPORT CONTENT.
