iLAMP

Enterprise : Management : Article
The 10 don'ts of corporate reporting
By Jonah Stephen, Special to CNETAsia
Thursday, August 26 2004 2:33 PM

Editor's note: This is the final in a series of three features on corporate reporting. Check out the first and second instalments.
Reporting processes ensure that IT departments and IT vendors deliver information on demand, or as scheduled, to all stakeholders in an enterprise.

Here are ten common mistakes and what you can do to avoid making them:

1. Don't assume stakeholder commitment
It's important that the stakeholders who utilize reports are consulted on how reporting processes are designed and implemented. Not involving them in planning and implementation could lead to a poor outcome.

This can create a lack of involvement on their part, in subsequent stages of the project. At worst it could result in delivering excessive or inadequate information. Not involving them during the building process is acceptable if they are consulted in the roll-out of the reporting process. Failing to offer them previews on the roll-out could affect acceptability of the reporting process.

Hence, milestone-based stakeholder reviews of the project are very important to ensure a project's success.

2. Don't ignore prototyping
Today's modern tools are very friendly in terms of initial development for prototyping, which makes it tempting to create a good reporting process and roll-it-out without prototyping.

Prototyping should be used to test the rigors of process implementation for information quality and application scalability. A medium to complex scenario(s) is recommended for building the prototype. The prototype needs to address data collection-interface to heterogeneous data sources, data processing, information publication and subscription, information security, application scalability and flexibility.

Moreover, prototyping helps you present with newer forms of presentation such as Dashboard, Visualization and Scorecards.

Hand-in-hand with prototyping is the need for evaluation metrics. Here are key metrics to consider:

* Process cycle time for each user group
* Number of human interfaces required to execute the process
* Repeatability of the process in unit- or real-time
* Usability
* Scalability
* Consistency of the output across different publishing formats
* Flexibility to enhance or add new processes

3. Don't be rigid
Think of how you can loosely couple the applications. Do not hard wire. Allow room to change and grow.

4. Don't be fixated on tools
Reporting processes need to be implemented using robust, cutting-edge tools and technology. Choose a development platform that will help you evolve, grow and change your business needs. The tools you choose must dictated by your needs in report-authoring and management, and not the other way around.

5. Don't be a reporting hog
Share the responsibility of providing information with the reports information input providers. These are typically line-of-business (LOB) heads, region or unit heads. Enable self-service for regular and on-demand information needs of the users; it will help free up IT resources. Publish report management policies along with the reports. Include the owner, as well as escalation or support contacts.
6. Don't expect ERP to do all
Enterprise resource planning (ERP) or LOB applications are utilized to automate business processes and improve efficiency. ERP's reporting is designed to report information in direct fashion, such as from say the origination of an order to its shipment.

Keep in mind, however, that your ERP and its reporting system are not designed to report using historical information or information prior to an order entry. Nor the post shipment/delivery, which covers competition, partners and vendors. So attempting to build comprehensive enterprise reporting using the ERP reporting system can be ultimately limiting.

7. Don't ignore user-friendliness
Usability can be your carrot to encourage users to adopt a new reporting system. Do not assume that your users can digest, or even tolerate, information in whatever form you provide. Users need information in many forms for consumption depending on their role in the organization.

Customize. Offer good visualization to executives, interaction and data richness to power users and simple browsing for the ordinary users.

8. Don't keep adding new reports
Or risk information overload and management mess. Before you create a new report, explore the possibility of customizing or reusing an old report. Be warned that as the number of reports increase, versioning and operational management--which includes security, logging and monitoring--will also increase.

To simplify, increase interactivity through filters, parameters, or links to other reports. The best way to address a growing demand for new reports is to periodically review the reporting process and make changes where appropriate .

9. Don't share reporting application resources
Reporting applications that implement the reporting process are ever growing and constantly changing. These applications tend to eat away all the resources that are shared, such as those set aside for development, support and maintenance.

Installing the reporting application in a separate server, and monitoring the application and its infrastructure will ensure that the resources are well managed.

10. Don't be complacent
Ah, the satisfaction of doing a good job! But in corporate reporting, there is no time to rest on laurels.

Reporting needs to continuously evolve in accordance with demand from businesses, regulations, user profiles and technologies. You should work towards having a reporting process good enough to trigger business process changes. For that to happen, make sure your reporting process can react to your business processes.

And establish a routine for periodic review of your reporting process. The review should focus on reducing process time by eliminating human interventions. It should be aimed at increasing information quality. It should also evaluate tools and technology.

Remember, it all boils down to one guiding principle: Keep the reporting process simple to understand and consume.

Jonah Stephen, a database and business intelligence veteran with more than 14 years industry experience, is the solution architect at Microsoft Corporation. Jonah has implemented multiple projects on BI and data warehousing for customers like Citibank and Frito-Lay.