The analyst macro was successfully run on the client machine, however, when tested on the server, the ODBC connection failed.  The ODBC Data Source Administrator was opened and the two ODBC sources were clearly configured.  The d-list being updated was opened and the import options were checked.  When connecting to the ODBC source, analyst displayed a message stating that there are no ODBC sources available.  This lead me to ask the question to the client “Is the OS for the server 64-bit?”.  The answer was “yes”.

IBM Cognos Planning is a 32-bit application, so the ODBC configuration set up on the 64-bit machine is not accessible to IBM Cognos.  Within the windows directory on the 64-bit machine there is a folder called “syswow64” which contains an executable file called “odbcad32.exe”.  This file opens up the ODBC Data Source Administrator under the guise of a 32-bit OS.  When this was opened there were no ODBC sources, so the sources were added and configured.

The analyst macro was rerun successfully on the server, and the CAC macro was also run successfully.

As more and more servers are now running 64-bit OS, this methodology to update ODBC sources should help you get the right result first time.  If you are planning an upgrade of existing systems to a new server that runs on a 64-bit OS, then the migration of ODBC sources should be included in the upgrade plan using the “odbcad32.exe” tool.

If you would like any further information, please do not hesitate to contact us on info@planitcpm.com.

1. Disparate build numbers found within the same version of software
2. Bug found in v10.1 where data entry at the consolidation point is allowed within Contributor

When a client is unclear of their requirements and their internal processes are being changed, the preferred development methodology is to use the waterfall method; create a prototype model and allow continuous feedback with the client. This helps the client structure their requirements and see a rapid turnaround in the model build as one is not trying to deliver all the components in one go, just the key requirements. The client can then visualise the application and see exactly what their requirements have “created”.
The Prototype model was deployed and sent on to the IT department. The client’s Contributor Administration could not “see” the deployment model. On investigation, the build number of the software was inconsistent between the client install and the local install used to create the prototype. The Client’s software install had occurred in March 2011 and the local install had occurred in October 2011. The only logical explanation is that an update in the software had been made which was not backward compatible, however this has not confirmed by IBM or even highlighted on the IBM Download Centre. Any updates in software should be expressly highlighted not just sneaked in! The issue was resolved by rebuilding the Contributor application via our Best Practice Lab server with the same instance of software as the client’s.

A fundamental principle of Cognos Contributor is that the workflow – the eList – is a representation of how an organisation collects data for review and final submission and therefore, data entry is only ever at the base level. The first piece of feedback from the client once the Prototype had been deployed to the sample set of users was that the consolidation point of the eList was not locked for data entry. On investigation, it was confirmed that with “multi-eList items” switched on, the contributor grid view showed all the base level nodes and the associated consolidated node as open for data entry.
There is no mention of this “feature” in the “Planning 10 New Features Guide”. In order to find a suitable resolution, the following Contributor Admin options were amended and logged along with the following results.

;

1. Switch off Reviewer Edit – Still able to input data at the consolidated level
2. eList – set the Review Depth to be None – still no change
3. With rights set to Submit – still no change
4. With rights set to Review – still no change
5. Planner Only Cubes – this works because one can no longer see the consolidated level when the grid opens up with the multi eList items option. Using this option would have been a step back for the client as their current system allows users to input into an Analyst cube and see the results on aggregation without being able to change the numbers on the aggregated level.
6. Switch off Breakback – this works. However, the users are required to be able to use the breakback functionality for the input level of their forecasts.
7. Access Tables – one cannot set access for anything other than the submission level node

The agreed resolution to achieve the desired results for the prototype model was to switch off Breakback. The client was subsequently upgraded to v10.1.1 and this resolved the data entry issue at consolidation point.
The software glitch in v10.1.0 seems to be related to the new functionality within v10.1.1 which allows reviewers to open up a selected number of nodes below a consolidation point rather than the previous default of “All”. When the user selects a few of these, the contributor grid opens up and there is system generated “Total” which simply aggregates the nodes that have been opened. This “Total” is open for data entry.
The significance of this is that users, for the very first time, can use breakback over the eList. Breakback can be elicited albeit, not for all the nodes of a consolidation point, but certainly for a selection of them.
Reshma Riyat
www.reshmariyat.com

1.    Introduce a Month’s Attributes D-Cube

A month’s attributes cube is made up of two dimensions.  The month’s attributes dimension, which contains all of the calculations to control the model; and the timescale dimension which should not contain any calculations at all.  The cube generally relies on one input – the current month.  This can be created in a one cell cube that is d-list formatted to the timescale dimension used in the month’s attributes cube and the data is transferred to the month’s attributes cube with a d-link.  Using a variety of built-in-functions (BIFs) and conditional formulas you can achieve results to show which months are actual months, forecast months, months to be read only, current month, current month lags etc.  All calculations are created in the month’s attributes dimension and most items will be d-list formatted with flags to be used in links as we will see later.

Now that the month’s attributes cube is in place, administration of the model can be made easier with the following techniques.

Note – the month’s attributes will become an assumption cube so remember to hide the cube using access tables.

2.  Automate Read Only Cells for Actual Periods

One of the advantages of implementing a month’s attributes process is to automate read-only cells for actual data.  Actual data will tend to be imported into the model from an existing source system and therefore end users should not be able to influence this data.  Existing models may currently use access tables to mitigate the risk of overwriting imported data, but this will require the access tables to be updated on a monthly basis.

The automation of this process is achieved by introducing an internal link to each cube that contains actual data.  The month’s attributes cube is used as a d-cube allocation using the actual month attribute to map the timescale dimensions within the d-link.  The effect is to make the actual months the target of a link and as a result, the contributor grid will show these months as read-only.  The data within the actual month timeframe will not be changed in any way as all other dimensions in the internal link will be mapped using matched descriptions.

3.    Control Links

Following on from the technique to mark actual months as read-only, we can now establish a process to allow data to be imported into the actual month periods without impacting the dataflow of the application.  An example of where this may be an issue is a link between a Profit and Loss d-cube and a Balance Sheet d-cube.  The P&L and Balance Sheet process in reality may be a complex process within a transaction based accounting system.  A planning application should aim to emulate the process but be simplified i.e. not a transaction system.  The actual balance sheet for the latest month will need to be imported, but the link from the P&L may flow data into the actual periods for certain items.  Importing can fail due to items being the target of a link.  To overcome this the following technique can be implemented.

Review each of the links in the application to identify the links that apply to the forecast process.  Using the month’s attributes cube as a d-cube allocation using the Forecast Months attribute, you can prevent the link from targeting actual periods.  This will then allow the administrator to import actual data into the target cube without the risk of the data being overwritten by dataflow within the application.

This technique can also be used to move actual data only throughout the model using the Actual Month attribute within the d-cube allocation.

4.    Manage and Maintain D-Cube Size

Managing the size of an application to maintain performance is a key responsibility of the administrator.  An application can become oversized easily if the application is not monitored or managed.  A technique to assist with the management of the application size is to review the time dimension used in each of the cubes.  If a cube exists to only hold actual data, the cube does not need forecast months.  Likewise, if a forecast calculation or process is being run, the cube, potentially,  does not need to contain actual months.

The month’s attributes cube can be used as a source for d-list updates.  Within the month’s attributes cube it is possible to create calculations such as Total Year, Total Forecast, Total Actual, Quarter Totals etc.  Using these items as Parent items in the d-list import attributes you can achieve automated calculations when updating the d-lists.  Within the import settings you can select which items you may wish to import to the d-list to be updated such as Forecast Months or Actual Months, along with any Parent items if required.  Following a monthly rollover, the d-lists can be updated which will increase/decrease the number of items in the d-list and update the calculations.

This technique can also be used in conjunction with actual data for other dimensions in the model, allowing the model to become a living blueprint in line with the activities of the business.

5.    Develop a Manager Screen to run the Administration

IBM Cognos Planning Manager is a simple tool designed to aid the end users in day-to-day modeling activity.  It is quite often overlooked in a Contributor implementation; however, a simple series of Manager screens can be very effective in the administrative processes that require regular attention.

With the techniques listed above, a Manager screen can be developed to allow the end user to state what the current month is, followed by a process to update the month’s attributes cube.  Instructions can be added to the macro to prompt the end user to execute Contributor Administration Console macros to complete the process and roll the model forward.  This step would fulfill the first three techniques above.

In addition, a macro could be written to update all of the timescale dimensions (or other moving dimensions) followed by a prompt to run more Contributor Administration Console macros to achieve the results described in technique 4.

As a result, the administrator does not need extensive knowledge of Analyst (although in-house product knowledge is encouraged).  The processes can be shared easily with other team members and succession planning is a less daunting and time-consuming exercise.

Conclusion

Administering an IBM Cognos Planning application need not be a time consuming exercise on a monthly basis.  With a good design brief and strong product knowledge it is possible to automate most (if not all) of the required administration tasks.  The techniques above should be included within the design of a system if there are requirements to control the model behavior identified in the project scope.  The above techniques can then be implemented in hours rather than days during the build.

If you would like further information to enhance your IBM Cognos Planning systems please leave your comments and someone from the Planit CPM team will be in touch to discuss.

One of the big selling points of IBM Cognos Planning is the ability to apply breakback to efficiently update detailed data.  Breakback works by entering a value in a calculated cell, and then the formula is reverse engineered and the detail cells are updated based on previous data that has been entered into the cube.  The process is extremely powerful when applying profiling to nominal items.

Example:

In this scenario a 4-4-5 profile is required to allocate quarterly totals across a time dimension.

In the above calculation the value of 13 is insignificant, except for the fact that is shows the sum of Jan, Feb and Mar.  Once the profile has been applied, the Q1 value can be updated to give a result illustrated below:

This process can be used in all types of dimension where a calculation has been set, however, performance issues may exist if the calculations are complex or the dimension hierarchy is detailed.  Performance issues can be monitored by run the d-link that updates the d-cube.  If the breakback element that runs across the bottom of the screen seems to take an usually long time to update then the following technique may be used to increase model performance.

Forward Based Calculation to Perform Breakback Result

The forward based calculation technique avoids breakback calculation completely by adding a new calculation dimension to the d-cube.  This does have a sizing impact on the model, so this needs to be assessed before applying the technique.  The calculation should consist of a minimum of 4 items (5 if a weighting item is required) to perform the calculation.  The first step is to run a link to populate the basis of the detailed result profile e.g. last years sales [1].  The second link then populates the TOTAL of this base value [2].  The third link then imports the required value e.g. the value of the item at the total level [3].  The fourth item then calculate the item that performs the breakback result [3]*[1]/[2].

This technique does increase the cube size and increase the number of required links, however, the performance impact can be extremely effective.  An example where this technique was applied increased the performance of a d-cube update from 30 minutes to 2 minutes.  In this example, the cube size was 1.5 million cells and the breakback occurred on a products dimension that contained a complex hierarchy consisting of approx 400 products.  The breakback basis was to import the net sales value in detail (the profile) and the Cost of Sales was entered in Total Products and the calculation process was triggered.  The breakback was then performed over approx 100 calculations.  The new dimension added brought together the net sales and the COS totals to calculate the COS detail by product.

To simplify, it maybe worth thinking of the process in this way.  To perform the forward based calculation, only one calculation is being done in the new dimension.  When breakback was applied to the example above over 100 hierarchy calculations were being re-engineered.

In summary it is always worth checking to see if performance issues exist in Analyst models.  D-cube size is the biggest restraint in an IBM Cognos Planning model, although there are techniques to manage cube size.  It is always advisable to build the forward based calculation alternative in a test library to compare performance.  If performance is increased, develop the revised solution in the live model.

From a planning perspective, the focus was heavily weighted on TM1.  For the Enterprise Planning Community that attended the conference, this initially sounded alarm bells.  Where was IBM taking Enterprise Planning?  Was the EP road turning into a dead end?  Well, there is no doubt that IBM will be pushing TM1 as the planning tool as TM1 is more technically advanced in terms of performance than IBM Cognos Planning.  However, the road is not closed for EP, just a mere diversion from the super highway, but with significant improvements – IBM released IBM Cognos Planning 10.1.

IBM Cognos Planning 10.1 was not promoted significantly at the IoD conference.  There was one major seminar that lasted an hour to discuss the improvements IBM Cognos 10.1 offered (this required a repeat session due to demand).  But that was it.

The biggest improvement is how Contributor can now cope with sparsity more effectively when cut-down has been applied.  This is due to the new process that uses Access Blocks as opposed to the old cut-down process that can take a significant amount of time to run during a Go To Production process.  IBM have stated that this improvement in performance allows IBM Cognos Planning models to become more scalable with models in excess of 30 million cells performing efficiently (providing cut down has been applied).  I will be running performance testing and stress testing comparing IBM Cognos Planning 8.4 and IBM Cognos Planning 10.1 to see the results for myself.

Other new features of IBM Cognos Planning 10.1 include the ability to highlight cells in the Contributor Web Client and seeing a summation of the results very much like MS Excel.  This function is limited to summation and maybe one day we can expect to see average or count as additional features.

IBM has improved the efficiency of running macros within the Contributor Administration Console. It is now possible for parallel running of macros making the platform more stable when it comes to automated processes.  In addition, a macro can be started or restarted at a specific step making the process more efficient if a macro fails.  An additional macro is also now available to run the Model Review Tool giving the application administrators easier access to the structure of an application to manage efficiency and trouble-shooting.

Also within the Contributor Administration Console, preview nodes are now available to view different e-list items with access tables applied.  This will have a significant impact on the development of applications with access tables to save time in running the GTP process to view the impact of implementing changes to access tables.

Improvements from an integrity perspective include the ability to apply a non-admin user account to the planning server to run automated processes.

IBM are clearly focussing their strategy on implementing more planning solutions using TM1, however, the “sunset” strategy on IBM Cognos Planning is still a long way off – just look at how IBM Cognos Finance is still going.  With the developments seen in IBM Cognos Planning 10, IBM are going to support this latest version for a further 8 years, plus when the next release is launched, another 8 years from that date.  The wheels are certainly in motion for even more improvements with aggregated data being handled more efficiently to improve reconciliation time.  I am looking forward to working with this latest release and the subsequent releases in due course.

The first of the recent projects I have worked on was left in the control of a contractor.  The client had taken on the contractor for work in a specialist area (not IBM Cognos Planning), but there had been an element of exposure to Planning implementations in the past.  This is where I filled the knowledge gap.  I scoped and designed the solution for a basic budgeting process, however, I constantly faced rejection for my ideas from the contractor (not the client), who then tried to implement a contributor application sized at 45 million cells!!  It didn’t work.  During this period the project slipped, and with no direction from the client the contractor continued to call the shots.  After two months of work, the client did not have a fully working solution and missed the budget process start date despite my best efforts to take control of the project from the contractor.

In contrast to this project, I have been involved in another budgeting exercise that was run by both client and IBM Cognos partner.  The team was made up of two project managers (one internal, one external), and a development team of four (two internal, two external).  The client’s employees faced the usual issues of having to do their jobs on top of implementing the project, but the majority of the implementation was completed by the external consultants reporting into the client.  Meetings were held weekly at a designated time, with members of the team having daily meetings to resolve smaller problems.  On a Monday morning, everybody knew what each person was doing that week with documentation being freely shared by all parties.  Knowledge transfer was able to take place, and the project was handed over to the client for them to maintain going forward.  The project was completed within budget and deadlines were met.  Phase two of this project has now been planned to set up a forecasting process using the IBM Cognos software.

Both of the clients above were in similar industries and similar in size.  The approaches, as you can see, were somewhat different.  I personally enjoy working with different organisations to see how they approach different aspects of work.  Some are better in some areas than others, but when it comes to this type of work, project management goes a long way.  When using an external party the implementation should be collaborative with each party having their distinct responsibilities in the delivery of the solution.  This way, accountability lies with all involved and the likelihood of success is greater.  I feel quite lucky to have experienced a badly managed project as I now have the insight to the warning signs and can take appropriate action.  I am even luckier to witness more project successes and can continue to develop my own project management skills to ensure the solutions I deliver are a success.