Are you getting an accurate view of your enterprise?
Operational data can be an invaluable source of business information. Designing a financial reporting solution that can leverage this resource can be well worth the effort.
Business Intelligence analysis based on disparate corporate data can lead to unpredictable results. Traditionally, business intelligence systems have been separate from online systems and they use a copy of the operational data, which by its nature is a subset captured at some earlier point in time. As enterprises grow, merge, and expand, additional lines of businesses and organizations come with their own data and information needs. As data is summarized and filtered for each new reporting system, this approach requires additional processes for accounting, auditing, reconciliation, and restatement.
All of this contributes to a reporting structure that is, in general, distanced from the original data source. It may rely on incomplete and/or untimely data and bear the burden of complex reconciliation and restatement processes. In addition, with so many copies of the data, IT infrastructure teams must handle increased levels of network traffic, server and storage resources, database administration, and workload management, as well as the risk associated with distributed privacy, security, and audit issues.
Solution for the Scaling Problem
The IBM® Scalable Architecture for Financial Reporting™ (SAFR) solution from IBM Global Business Services is designed to report efficiently on large volumes of transactional data. It is based on a set of software components embedded with patented technology, and it may be customized for use with new or existing data extraction and reporting applications. SAFR's ability to report directly from operational data means that it can rapidly produce a large amount of timely, consistent, and transparent outputs. It is highly scalable and can be easily updated to accommodate changing business needs.
SAFR is often used when operational data resides on System z™ and high-volume, complex reporting requirements create workloads that are difficult to manage using traditional techniques or tools. SAFR is designed to do the following:
Reduced reconciliation and restatement pain
SAFR can help you avoid keeping extra copies of the data, minimizing reconciliation problems. While other reporting techniques require preprocessed files that are already summarized, filtered, and/or denormalized, SAFR can enable a single version of "the truth" with a single-pass architecture that can facilitate reconciliation.
SAFR can also enable simpler data structures, requiring less extensive data conversion and keeping data in its original form. Other reporting techniques have complex data structures that make it difficult to change the view of historical data,such as when you need to redraw roll-up structures, make retroactive adjustments, or backdate transactions. In contrast, SAFR can perform effective-dated lookups to allow users to view the data as of many different points in time.
A better way
Business information systems are built on a relatively simple model that has been relatively consistent since the beginning of accounting. Transactions are posted using classifications to a summary structure. All reporting and analysis is done from the summary structure. Attributes captured on the detail transactions but not posted to the summary structure are effectively lost from view. A simple example is the accounting model, with journals, postings, ledgers, and reports.
Summary structures provide immediate information, but at a cost in terms of complexity. When those attributes which have been lost are needed for a business decision, we usually create another summary structure. But each additional summary structure creates a need to reconcile between structures. If the attributes are completely different, reconciliation becomes difficult, as does restatement or reorganization. Reconciliation of two reports or systems is significantly different from reconciliation of multiple systems and reports. In almost all businesses, this proliferation of systems and summary structures has resulted in a very complex environment.
The answers provided by these summaries can be completely different. If the answers come from the summaries produced in multiple ways from the same source they may be difficult to reconcile. But if they come from different sources, the job can become nearly impossible. The result can, at best, decrease confidence in decisions or, at worst, result in bad decision-making.
As a general rule, a better answer is to strive to use the detail to create transitory summary structures. The transaction details usually have all the attributes needed for reporting processes. If reporting rules are separated from transaction systems, they can change over time using the inherent flexibility of detailed history data. The summary structures should be viewed as temporary, rather than permanent, and be produced from the same detail. This eliminates the need for reconciliation.
The financial advantage
In practice, SAFR is much like a "factory for reports." Factories are able to manufacture products inexpensively on a per-unit basis because of the efficiency of sharing resources. Similarly, SAFR can achieve economies of scale by executing multiple reports simultaneously and sharing resources. If you're already running forty queries or reports, the forty-first report adds just a small incremental cost because you're already scanning the source table, and you may be able to share the table join information. Given the number of queries that SAFR can execute simultaneously, the SAFR solution may be very inexpensive when evaluated on a cost-per-report basis.
IBM Mainframes just got even more cost competitive. Let us show you how with a consultation. Call us at 1-888-SHOP-IBM.
We're here to help
Maximize the business value of your data, with this new IBM offering.
For assistance, contact us directly by sending an e-mail to: AskSAFR@us.ibm.com
Browse z Systems
IBM Scalable Architecture for Financial Reporting
Harnessing Economies of Scale for Enterprise Intelligence