February 2012
S M T W T F S
« Jan    
 1234
567891011
12131415161718
19202122232425
26272829  

Podcast Feeds

  • Subscribe to the RSS Feed

TM1 Tricks From The Field, Part 2

6.  LEVERAGING CONTROL CUBES FOR SECURITY - Control Cubes can be useful to view attribute or security information.  If migrating from Planning, it may even be possible to use an existing Excel spreadsheet to load security via a TI Process [into the Control Cube].

7.   CONFIRMING PROPER DIMENSION UPDATES -If a dimension, particularly a GL related dimension, is being updated via a TI Process, periodically open the dimension via the dimension editor and click All followed by a Hierarchy Sort.  Condense the top parent.  If the entire dimension doesn’t collapse or there are lone ‘n’ items visible, the dimension may not be updating properly.

8.  DEFINING RULES - Avoid using Aliases in Rules.  Yes, Rent is easier to understand in a rule than [Account] 7552 and TM1 can read an alias however an alias is more apt to be modified.  If Rent because Bldg Rent, the Rule is now broken.  Use comments to explain the purpose of the Rule e.g  #This rule calculates monthly rent (Account # 7552).

9.  USING A TEXT EDITOR LIKE NOTEPAD - Always use a text editor to copy Rules.  The TM1 Rule editor cannot read the smart quotes used by Word.

10. FIXING A CORRUPT RULES EDITOR - If your rules editor corrupts, try copying the rules to a text editor, delete the Rules [cube via Architect or Perspective], [re]creating the rules [cube via Architect or Perspectives] and copying the rules back from the text editor.

TM1 Tricks From The Field

CREATING ALIASES - When creating aliases, use consistent attribute names. Name or Desc will usually suffice. (We frequently find that name is used on one dimension, desc is used on a couple others and description is used on a few more.) This reduces those “uh oh, what did I call that attribute” moments when creating a process or updating rules.

Software Purchase Price – Allocating a Portion of the Costs to Maintenance

Most of the major software vendors sell their licenses and include the first year of support and maintenance. As a client, your accounting department will probably ask you to separate out the cost of support and maintenance from the license cost. So, you ask your vendor to break it out and they may respond that there is no break out as it’s included.

Let’s discuss why the accountants need it separated in the first place. Accountants are governed by the AICPA guidelines, SOP 98-1 that basically states that they need to allocate the costs of maintenance out of the purchase. They then need to expense the maintenance where the license is capitalized and therefore amortized over a number of years.

Upgrading to IBM Cognos 10 BI? Consider Using Lifecycle Manager to Help Validate the Migration

If you are considering an upgrade to IBM Cognos 10, you MUST check out lifecycle manager. Formerly known as Upgrade Manager, IBM has added a number of new features and rebranded it as Lifecycle Manager. It is an application that validates IBM Cognos BI report content during an upgrade by comparing reports that run in different versions of IBM Cognos BI.

Incorporate a Naming Convention in Your Model Build

TM1 is great for organizing your planning models. Make the most of this and incorporate a naming convention for your dimensions, views and TI processes. This makes building, maintenance and training much easier in the long run, especially when you have more than one Admin. Design a simple blueprint of your naming convention at the beginning of your implementation and keep it in your application folder for quick reference. Another tip is to use the underscore in lieu of a space in titles, whether it be your cubes, dimensions or the title row of your data import. For example, when creating a dimension using TI, I prefer that the variable name to show up as “Element_Name”, instead of “v1” if the underscore is not used, as would be the case if the column title was “Element Name” vs “Element_Name”.

The Life of a Road Warrior

Five Star Hotels . . .Five Star Restaurants . . .Well, we can all dream, right?

I’ve been consulting for over 10 years and I’ve had dinner at a high end restaurant once (and ate very lean for the duration of the trip). I frequently live on sandwich shop fare. A larger size sandwich makes a great lunch/dinner combo. I once lived on hoagies/subs for the duration of an assignment, about 6 weeks - lunch and dinner; I think I tried everything on the menu and I am not a fan of cold cuts. This was not an attempt to curtail costs decision; this was a ‘I don’t want to starve to death’ decision as it was the only place within walking distance to eat. (A rental car was not part of the agreement or at least not the reimbursable part.)

Power User Benefits of Moving from IBM Cognos Planning to IBM TM1 Part 2

This is the second piece to the story on why an IBM Cognos Planning client would consider moving to IBM Cognos TM1.

Power User Benefits-

The power user license is the TM1 Modeler. The role is similar the Enterprise Planning Modeler in that this person typically is responsible for building, modifying and deploying the TM1 Planning model to the end users (Contributors).

End Users Benefits of Moving from IBM Cognos Planning to IBM TM1

There’s been a lot of discussion on why an IBM Cognos Planning client would consider moving to IBM Cognos TM1. So, I thought I would do a little brain dump on my experience with clients. Today, I’ll start with the End User.

End User Benefits-

End users can choose from a couple different user interfaces. I will focus on the TM1 Contributor user interface for TM1 as it closely resembles Planning Contributor. It includes some functionality we have been requesting for years.

Defining Successful Test Scripts for an IBM Cognos Implementation

A key step in a successful IBM Cognos implementation is testing. Many clients struggle with what to include in their test scripts. Here’s a little Lodestar Solution tip.

As you go thru the design phase, make sure all power users have 3×5 sticky notes. As you define your design, write down each process that you believe should be thoroughly tested on a sticky note. Include on it a description, expected outcome, data requirements, and foreseeable issues.

Database Documentation Rescue

Having to create documentation is like having to go to the dentist. You know you have to go and you dread it every six months. Documentation is similar because everyone dreads it and whenever it is mentioned you can find hundreds of reasons to do other things until your teeth start to hurt.

Well, I have a great dentist for you and your Sql database. The product is called APEX SQL. First, before I give you a review and how to use it, there are few points that I have to make. The product only works if you have a normalized database with proper indices, primary keys/foreign keys, and good object naming conventions.