Contact Us
Partner Portal
Help Desk

Improving IBM Cognos Upgrades

IBM regularly releases new versions of its business intelligence software platform, IBM Cognos. Companies must upgrade to the latest and greatest version of Cognos in order to reap the benefits of the new features. Upgrading Cognos, however, is not always a simple or smooth process. There are many documents available that outline the Cognos upgrade steps, but the potential for uncertainties during and after an upgrade still exists. Therefore, it’s important to have a methodology and tools in place that help reduce these unknown variables and improve the management of the upgrade project.

The following is a condensed excerpt from our white paper that provides a methodology and discusses tools that improve the IBM Cognos upgrade process.

The Methodology

Motio’s upgrade methodology contains five steps:

1. Prepare technically: Plan the appropriate scope and expectations
2. Assess impact: Define the scope and determine workload
3. Analyze impact: Assess the impact of the upgrade
4. Repair: Repair all problems and assure they stay repaired
5. Upgrade and go live: Execute a secured “go live”
Cognos Analytics Upgrade Methodology

During all five upgrade steps, project management is in control and proficient in managing project changes and progress. These steps are part of the bigger picture of leveraging capabilities, and educating and delivering business value.

1.  Prepare Technically: Set appropriate scope and expectations

Key questions that must be answered in this phase to assess the current production environment are:

  • How many reports are there?
  • How many reports are valid and will run?
  • How many reports have not been recently used?
  • How many reports are just copies of each other?

2.  Assess Impact: Narrow the scope and determine workload

To understand the possible impact of the upgrade and assess the risk and amount of work, you need to gather intelligence about the Cognos BI environment and structure the content. To structure the content, you need to make several test projects. This gives you have the ability to break the project up into manageable pieces. You will need to test in order to assure value stability, formatting stability, and performance stability.

3.  Analyze Impact: Assess the impact of the upgrade  

During this step you will run your baseline and determine the expected workload. When all test cases have run, you have created your baseline. During this process, some test cases may fail. The reasons for failures must be evaluated and can be classified as “out of scope.” Based on this assessment, you can adjust project assumptions and improve timelines.

Once you have your Cognos baseline, you can upgrade your sandbox by following the standard IBM Cognos upgrade process as explained in IBM’s Cognos Upgrade Central and Proven Practice documents. 

 After you have upgraded IBM Cognos, you will run your test cases again. MotioCI captures all relevant information and instantly shows the results of the migration. This will provide several indicators of the workload.

To read the rest of the Cognos upgrade methodology, along with a more comprehensive explaination of all five steps, click here for the white paper. 

Ready to streamline and automate your BI & analytics platforms?
Get A Demo
Solutions
Products
About Us
Resources
Contact
  • Tel:1 (972) 447-9595
  • Toll Free:1 (833) 855-3073
Follow Us
Youtube Linkedin Twitter
© 2024 Motio. All rights reserved
Scroll to Top
As the BI space evolves, organizations must take into account the bottom line of amassing analytics assets.
The more assets you have, the greater the cost to your business. There are the hard costs of keeping redundant assets, i.e., cloud or server capacity. Accumulating multiple versions of the same visualization not only takes up space, but BI vendors are moving to capacity pricing. Companies now pay more if you have more dashboards, apps, and reports. Earlier, we spoke about dependencies. Keeping redundant assets increases the number of dependencies and therefore the complexity. This comes with a price tag.
The implications of asset failures differ, and the business’s repercussions can be minimal or drastic.
Different industries have distinct regulatory requirements to meet. The impact may be minimal if a report for an end-of-year close has a mislabeled column that the sales or marketing department uses, On the other hand, if a healthcare or financial report does not meet the needs of a HIPPA or SOX compliance report, the company and its C-level suite may face severe penalties and reputational damage. Another example is a report that is shared externally. During an update of the report specs, the low-level security was incorrectly applied, which caused people to have access to personal information.
The complexity of assets influences their likelihood of encountering issues.
The last thing a business wants is for a report or app to fail at a crucial moment. If you know the report is complex and has a lot of dependencies, then the probability of failure caused by IT changes is high. That means a change request should be taken into account. Dependency graphs become important. If it is a straightforward sales report that tells notes by salesperson by account, any changes made do not have the same impact on the report, even if it fails. BI operations should treat these reports differently during change.
Not all reports and dashboards fail the same; some reports may lag, definitions might change, or data accuracy and relevance could wane. Understanding these variations aids in better risk anticipation.

Marketing uses several reports for its campaigns – standard analytic assets often delivered through marketing tools. Finance has very complex reports converted from Excel to BI tools while incorporating different consolidation rules. The marketing reports have a different failure mode than the financial reports. They, therefore, need to be managed differently.

It’s time for the company’s monthly business review. The marketing department proceeds to report on leads acquired per salesperson. Unfortunately, half the team has left the organization, and the data fails to load accurately. While this is an inconvenience for the marketing group, it isn’t detrimental to the business. However, a failure in financial reporting for a human resource consulting firm with 1000s contractors that contains critical and complex calculations about sickness, fees, hours, etc, has major implications and needs to be managed differently.

Acknowledging that assets transition through distinct phases allows for effective management decisions at each stage. As new visualizations are released, the information leads to broad use and adoption.
Think back to the start of the pandemic. COVID dashboards were quickly put together and released to the business, showing pertinent information: how the virus spreads, demographics affected the business and risks, etc. At the time, it was relevant and served its purpose. As we moved past the pandemic, COVID-specific information became obsolete, and reporting is integrated into regular HR reporting.
Reports and dashboards are crafted to deliver valuable insights for stakeholders. Over time, though, the worth of assets changes.
When a company opens its first store in a certain area, there are many elements it needs to understand – other stores in the area, traffic patterns, pricing of products, what products to sell, etc. Once the store is operational for some time, specifics are not as important, and it can adopt the standard reporting. The tailor-made analytic assets become irrelevant and no longer add value to the store manager.