We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.


The Need to Simplify Data and Reporting

Originally published September 17, 2009

We in information management need to understand simplification. Sometimes we believe its more important to provide a perfect and inevitably morecomplicated design when we should be focusing on fixing the actual business problem. Frequently this results in a white elephant solution that does not quickly or inexpensively deliver businessvalue.

This is not to say that simplifying is without its problems. Self-serve, independent data marts, without proper governance and close business involvement, can quickly multiply into a large number ofdisconnected solutions that become unsustainable. Governance and controls are still required.

What are some of the key points to simplifying the data and reporting environment?

Key Points

  • Ongoing expenses for redundant data and reporting rob the business of funding for new data and reporting. Help the business understand the true costs of redundant data and reporting.

  • With the business, assess the current data and reporting landscape. Identify redundant and one-off solutions as candidates for elimination and consolidation.

  • 80% is good enough. The return on dollars spent chasing the last 20% is quickly diminishing.

  • This exercise will produce pain in parts of IT and the business as change, especially reduction or elimination, is a threat.

Process

The key to simplifying is that it needs to be explicitly business process-centric. We need to work with the business in order to understand their key business processes. If we don't do this,how do we know which 80% is really value-add?

Operational Reporting

Many of the "reports" are actually business processes producing critical business data the business units need to run their business. The problem the enterprise is having on the whole is that those business processes were thrown together in reactive mode, with many units addressing the same need in radically different ways.

As the processes are understood and triaged, you can perform an application dismantling approach.

  • Operational Processes Move to application development or modules of vendor packages

  • Operational Business Intelligence (BI) Move to an operational data store (ODS)
Operational reporting is necessary when it supports a specific business unit. When multiple business units need the same reporting, it should be moved to the enterprise data warehouse.

Enterprise Reporting

Enterprise reporting in many organizations today means the business is producing data dumps and list reports from various sources. They are subsequently culled through, reformatted and augmented with other data to ultimately produce similar, but not the same, type of information over and over again. Leaders are left with inconsistent data and expensive shadow IT organizations that spend the majority of their time finding and aggregating data instead of analyzing it. IT organizations are left trying to explain why their numbers do not match the customer-supported systems (CSSs).

As mentioned previously, working with the business is key to identifying and eliminating redundancies in data and reporting. But you cant do that until you have a new solution that satisfies the business need. Enterprise reporting based on business functions is the solution.

Enterprise reporting abstracts the specific (operational) business processes and requirements into functional (management) requirements that support the entire enterprise, e.g., customer, order and item. This process simplifies enterprise data and reporting by creating single sources of truth. It is important to recognize they are not necessarily single physical structures. They can be spread out in various physical structures depending on the needs of the business; however, they do not duplicate data or reporting.

In addition to understanding the enterprise-wide functional areas, we need to understand the key performance indicators (KPIs), metrics, definitions and dimensions in order to create meaningful reports and dashboards. These measurements and definitions will almost certainly be inconsistent across the business units.

The business, not IT, must drive toward common measurements and definitions. This often requires them to reconcile business processes across organizations. It is difficult, but the rewards are great. Getting to a common set of definitions and measurements, we can simplify the data and the reporting, saving money for new work instead of ongoing spending on redundant and inconsistent environments.

Conclusion

Simplifying data and reporting provides consistent information to decision makers and saves money by providing single sources of the truth, consistent reporting and more efficient use ofvaluable human resources.

Ironically, simplifying is hard. The process is ongoing, not a one-time event. Initial savings in reductions and eliminations will quickly be reabsorbed into redundant data and reporting initiativesif not closely watched and managed. The allure of just one more dataset or report is strong as business units are usually incented more heavily on their own performance rather than the greatergood.

Business and IT must work together to be successful. In order to simplify, eliminate redundancies and create a shared environment, the business processes and reporting needs must be clearlyunderstood.
  • Timothy LeonardTimothy Leonard
    Timothy Leonard has more than 20 years experience in configuration management planning for data warehouses, operational data stores (ODS) and order entry systems.  He has led several large scale infrastructure hardware (SAN, Network) design for clients, and comes into companies to help maintain and enhance the existing environment for optimal performance capability.

    His expertise includes delivering best practice methodologies around solutions that are used to identify, control and track changes for projects – integrating touch points between multiple functional areas of the implementation team. Tim has developed procedures that enforce a formal method for managing change requests to baseline documents and software release schedules associated with data warehouse projects. A patent holder for an Internet order entry system, Tim utilizes his technical background along with his project management skills to impact all phases of a software development life cycle (SDLC) – focused on the distinct requirements and standards of data warehousing projects. He has hand-on experience with all phases of a data warehouse project life cycle, and has had direct responsibility for creation of a configuration management plan for enterprise data warehouses that track all actions and changes from project initiation through to production support. Tim is a featured speaker at industry and vendor events such as TDWI and DAMA.


Recent articles by Timothy Leonard

 

Comments

Want to post a comment? Login or become a member today!

Be the first to comment!