|
Everest (OutlookSoft Corporation) |
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.
Budgeting is a process rather than a single task. As such it consists of a number of steps or processes, all of which must be properly managed for an effective budgeting process. The importance of each of these steps being well managed increases as the size of the enterprise increases. Preparing a budget for an enterprise of any scale involves a number of issues, all of which must be addressed.
| Data management | In an enterprise of any size, data management in a budgeting system becomes a crucial issue. Consolidating data from the many hundreds or thousands of budgeting units worldwide can be a significant exercise. The aggregation alone, although easily handled by today's hardware, can be a slow, cumbersome process if the wrong software is used. And, as any financial professional knows, just adding up the numbers does not necessarily yield a meaningful consolidation. The consolidation may need to take account of issues such as currency translation, interdepartmental eliminations, allocations, cross-charges, accruals and many other accounting complexities. It will come as no surprise to readers of The OLAP Report that budget data is inherently multidimensional. No budget has fewer than the basic four dimensions (accounts or line items, departments or cost centers or companies, time and version). Typically most budgets will consist of six, seven or eight dimensions, the additional ones being drawn from a pool including products, customers or channels, sales people, region and so on. So, simply putting the budget data in any database, however capacious and powerful, is not enough. A specialist multidimensional database will provide, with relative ease, the slice and dice, multidimensional aggregations and analytical flexibility that a relational database will often struggle to deliver. |
| Data Capture | One of the most important issues in preparing a good budget is capturing the data. It must be captured from the right people wherever they are in the world. The people who are to be held accountable for the budget must be the ones from whom the data is captured. But this brings up problems of software deployment. If specialist software is to be used, it must be installed on the desktops of all personnel who are going to enter budget data. If there are thousands of desktops, this can be a daunting task. This is why Web-based, zero client footprint approaches are so popular today. Budgeting instructions must be clearly and efficiently communicated to all who participate in the budget. Again a Web-based approach facilitates this. Also data must be validated as closely as possible to the point of entry. It is important that data cannot be submitted without validation to ensure that it is consistent and in balance. Another example of the need for validation might be to manage proposed salary or headcount increases outside the corporate guidelines. These must be identified as part of the data capture and special managerial overrides permitted, if the system permits. Another aspect of data capture is the ability of the system to extract, transform and load data from other systems (eg, general ledgers, HR or CRM applications). The capabilities of budgeting systems in this area are perhaps less demanding than those provided by specialist ETL vendors provided as part of a data warehousing application. Nonetheless, the ability to easily extract data from source systems, transform it, validate and load it into the budgeting system is crucial. |
| Financial modeling | All too often, budgets are prepared with insufficient attention paid to modeling. A well thought-out financial model which accurately reflects the sensitivity of the key financial numbers to a selected set of inputs is invaluable. Some companies have always used modeling to an extent. For example, banks have always modeled interest income and expense based on interest rates. But many companies have little or no modeling as part of their budgeting exercise. Factors such as interest rates, inflation drivers, raw material prices, days sales outstanding (DSO), energy prices, labor rates and tax rates should all be part of an efficient budget model. This allows the effect of changes in these key factors on the overall budget to be readily seen. A good budgeting system must include a financial modeling language with the following characteristics:
|
| Consolidation | Financial consolidation is, in a technical sense, nothing more than adding up numbers. In another sense it is an accounting fiction, the objective of which is to attempt to show what the overall financial results of an enterprise are, despite the fact that they are operating as different operations, in different currencies, around the world. Once the financial results are aggregated, many things must be done before the consolidated results are meaningful. These operations include:
|
| Process control and collaboration | The more people that participate in the budgeting process, the more important process control becomes. If the manufacturing cost centers are still on revision one, while the selling and marketing units are into revision two, the results will not be meaningful. Also guidelines and instructions must be clearly and quickly communicated and revised. Finally, all participants must be able to quickly ascertain the status of the whole budgeting process. Another key to the collaboration process is the ability to share instructions and supporting documents. Overall guidelines and planning instructions must be shared with all participants in the process. Participants must be able to submit supporting documents in whatever form is appropriate (Excel workbooks, PowerPoint presentations, Word documents, etc.). Although this is of primary importance for the budgeting process, it also helps to coordinate the consolidation of actual results too. |
| Reporting | Clearly, the ability to easily and quickly produce reports, in any format, showing any or all parts of the budget and consolidation, is crucial to the process. Reports should be easily accessible to all, easily deployed and subject to a comprehensive security model. |
Without doubt, the most widely used budgeting tool of all is Microsoft Excel — almost all business professionals have it on their computers, and the majority use it for at least ad hoc plans and analyses. Excel is a powerful piece of software, indispensable to many professionals, particularly financial analysts, but Excel alone is a very poor enterprise budgeting tool. Although it is powerful at manipulating and presenting data, Excel is poor at data management and process control and weak at financial modeling in more than two or perhaps three dimensions. Unfortunately, many companies who prepare budgets with Excel alone are not aware of the inherent problems in using the simple spreadsheet for enterprise budgeting until problems mount up. Indeed, many senior managers may be unaware that better budgeting tools exist while more junior staff often lack the experience to appreciate the importance of features such as collaboration, data management and modeling that Excel lacks. Such issues are often exposed when staff turnover results in a new staff member being unable to enhance, or even correct, an undocumented, poorly structured and often extremely large Excel workbook. Or perhaps significant flaws are only found when management or auditors question the results of an Excel model. This is even less acceptable than it was before legislative changes such as Sarbanes-Oxley.
Hyperion and Cognos are the leaders in the specialist budgeting market, the former with Pillar and Hyperion Planning, and the latter with Cognos Planning (the former Adaytum). Hyperion Planning is an application based on Essbase, but Pillar and Cognos Planning use their own proprietary engines (Cognos Planning actually has three distinct proprietary engines).
Hyperion Essbase and Applix TM1 are also often used for building budgeting applications, and are excellent at data management and financial modeling but lack any sort of process control, which must be built into the application by the user. For this reason, Hyperion developed its successful Planning application, but Applix was less successful with its attempt to market a Web-based planning application based on TM1.
We have, therefore, identified the following headings under which to evaluate budgeting packages:
Everest uses SQL Server 2000 as its underlying database platform. The OLAP server component is used for the multidimensional data and the relational database component is used to store other data such as supporting documents and control information. Since Analysis Services is a general-purpose multidimensional database and has no native concept of financial awareness, the OutlookSoft platform requires that certain dimensions with particular significance in the financial world be identified. These dimensions are accounts, entities, time, and category. The administration module is hosted in Microsoft Excel and dimensions are built and maintained in Excel. This makes Everest unusually flexible and easy to set up, but it also limits the maximum number of members of dimensions to 64k. This is unlikely to be a constraint in the financial analytical world and, even if it were, it simply means that the dimension would have to be built directly from a relational table, rather than through Excel (which would, in any case, make more sense for such large dimensions). Members are given a unique key or member name, and everything else is defined as columns in the spreadsheet which Everest stores as member properties.
Each dimension must be identified as one of the special four or user-defined. Defining the dimension as, for example, an account type of dimension means that OutlookSoft will automatically assign an appropriate set of required properties to the members of that dimension. For example, the required property ACCTTYPE indicates the type of account as Asset, Liability, Income or Expense. The CURRENCY property of entity dimension indicates which currency that entity reports in. This approach allows the generic, multicube, multidimensional, Microsoft OLAP server to be turned into a financially-aware engine. Users can and do add their own member properties in addition to the required ones, which can then be used by the OutlookSoft application. Hierarchies are optional in some dimensions (eg category) and are defined in the others by including one or more parent columns in the spreadsheet. Any column headed PARENTH followed by a digit is used to build a hierarchy in the dimension. This makes designing the dimension easy and multiple hierarchies, which are particularly common in entity dimensions in this type of application, to be easily accommodated.
Note that OutlookSoft has chosen an unusual, and in our opinion confusing, terminology. The entire application is referred to as an application set. Individual cubes within an application set are referred to as applications rather than cubes. We would much prefer the adoption of the standard industry term ‘cube’ and think that designers would find it less confusing. Indeed OutlookSoft uses the term ‘cube’ itself when referring to portable data cubes. OutlookSoft responds that this terminology is justified because it handles multiple different applications within one application set.
Everest allows as many dimensions as are needed in addition to the base four (many other packages have hard-coded upper limits for the number of dimensions). Currently, all applications or cubes must contain the required four dimensions. This means that even an exchange rate cube must contain the required four dimensions. This appears to be a design oversight which we had expected to be corrected by now, but this has yet to be done. This requirement can be worked around, but is perhaps a sign of a still immature product:
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.