Your shopping cart is empty!
Reporting refer to any activity that leads to reports.
Business Reporting or Enterprise Reporting is a fundamental part of the larger movement towards improved business intelligence and knowledge management. Often implementation involves extract, transform, and load (ETL) procedures in coordination with a data warehouse and then using one or more reporting tools. While reports can be distributed in print form or via email, they are typically accessed via a corporate intranet.
With the dramatic expansion of information technology, and the desire for increased competitiveness in corporations, there has been an increase in the use of computing power to produce unified reports which join different views of the enterprise in one place. This reporting process involves querying data sources with different logical models to produce a human readable report—for example, a computer user has to query the Human Resources databases and the Capital Improvements databases to show how efficiently space is being used across an entire corporation.
Enterprise reporting (or management reporting) as the regular provision of information to decision-makers within an organisation to support them in their work. These reports can take the form of graphs, text and tables and, typically, are disseminated through an intranet as a set of regularly updated web pages (or "enterprise portal"). Alternatively, they may be emailed directly to users or simply printed out and handed around, in the time-honoured fashion.
Types of Enterprise Reports
Components of Reporting System
The enterprise reporting components are described below:
Note that usually most of these systems are already in place (in some form or other) and controlled by other parts of the organisation. For example, Enterprise Resource Planning (ERP) and Customer Relationship Management (CRM) could be source systems responsible for instrumentation, data supply and ETL. Also, the data store is likely used for transaction processing too by Finance, Sales and Marketing and HR. Similarly, whoever is responsible for IT Governance may also take a strong interest in the assurance aspects of enterprise reporting.
The extent to which these established components are a help or a hinderance will be a key determinant in the success or otherwise of your project.
Regulatory reporting requires companies to consolidate, calculate, and present their financial data in the most timely and accurate manner possible. But, with revenue and expense data residing in various disparate enterprise sources such as accounting applications, order entry systems, third-party payroll databases, and budgeting and forecasting solutions – how can an organization efficiently and effectively comply with these complex regulations?
Know the Guidelines
In many organizations, few stakeholders have full knowledge of all the guidelines and rules that govern the business. Additionally, legislation changes frequently, and the various federal, state, and local agencies are issuing new and revised laws all the time. Therefore, it is critical that you identify those who are most accountable for overseeing compliance with regulatory reporting guidelines, and put the appropriate measures in place to ensure that they are well-informed about existing rules, and keep on top of any new or revised ones.
It is also important to note that some regulatory bodies require companies to designate a senior representative to certify report contents, holding them personally responsible for the information’s accuracy and integrity. Choose this person wisely.
Assess Your Risk
Are your global operations, and such factors as accounting systems in multiple languages or currency conversions, hindering your ability to generate fast and consistent financial reports? Are consolidations and calculations manual, increasing the number of errors and negatively impacting data integrity? Or, do you lack an effective audit trail, so you can track how financial data has been entered, altered, or accessed?
Questions like these are critical to understanding where exposure for non-compliance exists, so you can take swift corrective action. Have a third-party “expert”, such as a consultant, come in and conduct an unbiased assessment of your current reporting processes and systems, and make recommendations for new procedures and tools to help ensure effective compliance.
Leverage Your Master Data and Metadata
Master data and metadata have both proven to be effective ways to enable improved regulatory reporting. For example, a master data management strategy allows companies to develop enterprise definitions, such as what “open” account status means in the case of a mortgage, a checking account, a line of credit, etc. This gives financial managers access to a common view of accurate and timely financial information from systems across the enterprise.
Additionally, metadata, particularly that generated by business intelligence systems, can help ensure the appropriate storage, retention, and disposal of mission-critical financial information – including that contained in unstructured formats such as emails and images. It also provides a virtual “audit trail” of financial information, such as what systems key accounting data resides in, how is it aggregated from various databases, or how expense, revenue, and profit numbers are calculated.
Corporate Governance is Key
Simply creating a report, and refreshing the data on a regular basis is not enough to guarantee ongoing compliance. If the data you are plugging into your report templates in inconsistent or inaccurate, then your reports will not meet the needed standards, and severe sanctions could result. Since financial data exists in many disparate systems across an organization, strict policies and procedures must be developed, documented, and enforced – and a governing body must be assigned to oversee them – in order to maintain the integrity of all relevant information across the enterprise.
Typical data warehousing queries
Many kinds of commonly asked business questions can be readily expressed as SQL queries. For example, anyone familiar with SQL can write a query that returns the quarterly sales of a given product in a given year.
However, many other commonly asked questions cannot be expressed so easily. Questions that require comparisons often challenge both the query writers and SQL itself. For example, a question requesting a comparison of weekly, monthly, quarterly, and yearly values is one of the simplest questions posed during a sales analysis, but expressing this question as a query represents a formidable challenge to the query writer, the query language, and the database server.
Business questions that request sequential processing are very difficult to express as SQL queries. To derive a simple running total, for example, data analysts typically run several queries with a client tool, then paste the results together using another tool. This approach is awkward because it requires a sophisticated user, floods the network with data, and takes place on a client that is typically much slower than a database server.
The standard SQL OLAP functions and RISQL extensions to SQL provide a better solution because they are easy to use, reduce network traffic, and perform a broad range of calculations that execute quickly on the server.
Difference between a database and a file is the way you can access them. You can search a file sequentially, looking for particular values at particular physical locations in each line or record. That is, you might ask, “What records have the number 1013 in the first field?”
In contrast, when you query a database, you use the terms that the model defines. You can query the database with questions such as, “What orders have been placed for products made by the Shimara Corporation, by customers in New Jersey, with ship dates in the third quarter?”
In other words, when you access data that is stored in a file, you must state your question in terms of the physical layout of the file. When you query a database, you can ignore the arcane details of computer storage and state your query in terms that reflect the real world, at least to the extent that the data model reflects the real world.
Writing Own Queries
When writing your own query, you define the set of choices and conditions that you want to use to retrieve data stored in the Warehouse. You determine such attributes as data elements to be returned (e.g., last name, city, age), conditions for selecting records (e.g., equal to or less than), and sort criteria (the order and priority in which results are to be sorted).
You may want to keep in mind some general questions to guide you in composing a query:
What information are you looking for? In what collection does this data reside, and which Business Object universe would be best to use?
Bear in mind the level of detail data you need, the time periods concerned, and which source system you would use to verify the data retrieved.
Once you have a basic idea of the results you need, consider how the query should be contrained -- by time period? account segment(s)? employee or organization names/codes?
What will you do with your results? If you are presenting them to others, you may want to include segment descriptions for those unfamiliar with codes. Also, if you plan to export the data, you may want to include objects which you have used to constrain your query, to better identify the data in the exported file. (For example, although you may have used Accounting_Period as a constraint, it might help to have the period appear as a column in your exported file, so you know what period that data represents.)
General Guidelines for Executing Queries
Queries often require complex conditions to return appropriate results. WHERE clauses (also known as query filters or conditions) reduce the amount of data to be processed in a SELECT statement (comprised of desired result objects or columns) by specifying that only those rows meeting the criteria in the WHERE clause are displayed. Depending upon which tool you use to query the Data Warehouse, your degree of control over the query language and operators will vary. For example, BusinessObjects and Microsoft Access employ graphical interfaces which construct appropriate SQL behind the scenes based on the tables and joins the user indicates. Oracle SQL*Plus, on the other hand, requires the user to write his or her own SQL statments. The Oracle database system, which forms the foundation of the Data Warehouse, permits the use of powerful SQL operators, some of which may also be available as post-query operators in your desktop tool.
The following guidelines are for all users of the Data Warehouse, regardless of query tool, and provide good practices for efficient querying: