Contact Us
Help Desk
Cognos Deployment

Post: Cognos Deployment Proven Practices

How to make the most of MotioCI in supporting proven practices

MotioCI has integrated plugins for Cognos Analytics report authoring. You lock the report that you’re working on. Then, when you’re done with your editing session, you check it in and include a comment to record what you did. You can include in the comment a reference to a ticket in an external defect-tracking or change-request system.

You can find additional details about how to set up the connection between MotioCI and your third-party ticketing system in the MotioCI Administrator’s Guide under Using MotioCI with third-party ticketing systems. A keyword (fixes, close) with the ticket number will close the ticket. Or, using a keyword like references plus the ticket number will write the check-in comment to the ticketing system and leave the ticket open.

The use of a ticketing system – like Atlassian® JIRA, Microsoft Windows™ Trac, or many others – aids project management by tracking specific tasks, issues and their resolution. Tickets provide a means of communication between authors or report developers and end-users, the testing team and other stakeholders. A ticketing system also provides a method of tracking defects and ensuring that they are addressed before promoting a report to production.

Typical Workflow for Report Development

To be clear, the integration of MotioCI with a ticketing system is not the only way that your team will interact with the ticketing system. Typically, as illustrated in the accompanying workflow diagram, the process of report development in a Cognos Analytics environment with MotioCI might be something like this:

  1. Backlog. A new ticket is created. A Business Analyst documents the business requirements for a new report and enters it directly into the ticketing system by creating a ticket. He places the ticket in the backlog state.
  2. Development. The backlog tickets can be prioritized in a number of different ways, but ultimately the ticket will be assigned to a report developer and tagged with her name. The state of the ticket may be changed to in_dev. She will create a new report. As she develops the report in Cognos Analytics, she will will check in her changes and reference the ticket in the check-in comment, like “Created new report; initial version; added prompt page and supporting queries, refs #592”. Or, “Added fact query and crosstab; filters and formatting, refs #592.” (In MotioCI, the hashtag number becomes a hyperlink directly to the ticket.) She may check out the report, make changes and check it back in with the ticket reference multiple times over a period of days.
  3. Development completed. After the Report Developer has completed the report and bench tested it, she notes in the ticket in the ticketing system that it is ready to be tested by QA and changes state from in_Dev to ready_for_QA. This state is a flag for the MotioCI Administrator, or role responsible for promoting Cognos reports, that the report is ready to migrate to the QA environment for testing.
  4. Promotion to QA. The administrator promotes the report and changes to the state to in_QA. This state lets the QA team know that the report is ready to be tested.
  5. Testing. The QA team tests the report against the business requirements. The report either passes or fails the tests. If the report fails QA testing, the ticket is tagged with the in Dev state, returning to the report developer for fixes.
  6. Testing successful. If the report passes, the QA team tells the administrator that it is ready to promote to production by labeling it ready for Prod state.
  7. Promotion to Production. Once the report is ready for production, final approvals can be obtained and release scheduled, perhaps bundling with other completed reports. The administrator promotes the report to the Cognos Production environment. He places the ticket in Done state indicating that development and testing are completed and it has been moved to production. This closes the ticket.

Management of the Report Development Process

This ticket management process implies and proven practices dictate that:

  • Every new report should have a ticket with the business requirements to design the report to.
  • Every defect should have a ticket to record any bugs or issues with a report.
  • Every time a report is edited, the MotioCI check-in comment should include the ticket number which was addressed.
  • Every report that is promoted from Dev to QA should have an associated ticket that an administrator can confirm that development has been completed and it is ready to be moved to the QA environment.
  • Every report that is promoted from QA to Production should have a ticket that has a history showing that development is complete, it has passed QA, it has received all required management approvals and has been promoted.
  • Every report in the Production environment should have a digital paper trail from conception to testing to fixing to resolution to approval and promotion.

This last point is a favorite of auditors to validate. She might ask, “can you show me how you confirm that all reports in the Production environment have adhered to your documented process of ticketing and approval?” One way to respond to the auditor might be to provide a list of all the reports that have been migrated and have her wade through the tickets to look for one that does not conform to your process.

Alternatively, and more ideally, you can provide a list of reports that do not adhere to the development and ticketing process which you have defined. That’s where this report will be useful: “Reports Promoted with no Tickets”. It’s an exception report of a list of reports which have not adhered to the best practices of having every report change tied to a ticket. This is one of the few reports you want to be empty. It will have no records if all reports which have been promoted have a ticket associated with it. In other words, a report will only appear on the list if it is in the Production environment and the report that was promoted did not reference a ticket number in the comment.

Process with Benefits

What are the benefits of the process, or why should you do this in your organization?

  • Improved team collaboration: The ticketing system may actually bring together individuals in roles who may not normally communicate. Report authors and end users, or project manager and the QA team, for example. The ticket trail provides a common place to communicate about a shared resource, the report under development.
  • Reduced costs:
    • Defects caught and fixed sooner are much less expensive than if they escape into production.
    • Improved efficiency – report authors are always working from a ticket which is a well-defined statement of work.
    • Reduced time through automation of manual processes
  • Improved documentation: This process becomes a self-documenting knowledgebase of defects and how they were resolved.
  • Improved forecasting and analytics: You can now track key performance indicators and compare them to service level agreements. Most ticketing systems provide these types of analytics.
  • Improved internal support: Your support team, other report developers (and, even, your future self!) can look up how similar defects were addressed in the past. This shared knowledge base can lead to rapid resolution of defects.
  • Improved end-user satisfaction: With direct access to developers through the ticketing system, users can expect rapid resolution of defects as well as monitor the progress of a requested report through the system..

Conclusion

This is one example of rich payoffs to following proven practices and the value of following well-defined processes. Further, the new MotioCI report, “Reports Promoted with no Tickets” can be a huge help in addressing questions from an auditor, or simply internal monitoring for adherence to corporate standards.

 

Ready to streamline and automate your BI & analytics platforms?
Get A Demo
Solutions
Services
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.