Page 175 -

174 Part II • Descriptive Analytics

are properly aligned (Hill, 2008). Following are the most common components of a
business reporting system.

• OLTP (online transaction processing). A system that measures some aspect
of the real world as events (e.g., transactions) and records them into enterprise
databases. Examples include ERP systems, POS systems, Web servers, RFID readers,
handheld inventory readers, card readers, and so forth.
• Data supply. A system that takes recorded events/transactions and delivers them
reliably to the reporting system. The data access can be push or pull, depending
on whether or not it is responsible for initiating the delivery process. It can also be
polled (or batched) if the data are transferred periodically, or triggered (or online)
if data are transferred in case of a specific event.
• ETL (extract, transform, and load). This is the intermediate step where these
recorded transactions/events are checked for quality, put into the appropriate
format, and inserted into the desired data format.
• Data storage. This is the storage area for the data and metadata. It could be a
flat file or a spreadsheet, but it is usually a relational database management system
(RDBMS) set up as a data mart, data warehouse, or operational data store (ODS); it
often employs online analytical processing (OLAP) functions like cubes.
• Business logic. The explicit steps for how the recorded transactions/events are
to be converted into metrics, scorecards, and dashboards.
• Publication. The system that builds the various reports and hosts them (for
users) or disseminates them (to users). These systems may also provide notification,
annotation, collaboration, and other services.
• Assurance. A good business reporting system is expected to offer a quality
service to its users. This includes determining if and when the right information is to
be delivered to the right people in the right way/format.
Application Case 4.2 is an excellent example to illustrate the power and the util-
ity of automated report generation for a large (and, at a time of natural crisis, somewhat
chaotic) organization like FEMA.

Application Case 4.2

Flood of Paper Ends at FEMA
Staff at the Federal Emergency Management Agency project manager and computer scientist, respectively,
(FEMA), a U.S. federal agency that coordinates from Computer Sciences Corporation (CSC) have
disaster response when the President declares a used WebFOCUS software from Information
national disaster, always got two floods at once. Builders to turn back the flood of paper generated
First, water covered the land. Next, a flood of paper, by the NFIP. The program allows the government
required to administer the National Flood Insurance to work together with national insurance companies
Program (NFIP), covered their desks—pallets to collect flood insurance premiums and pay claims
and pallets of green-striped reports poured off a for flooding in communities that adopt flood control
mainframe printer and into their offices. Individual measures. As a result of CSC’s work, FEMA staff no
reports were sometimes 18 inches thick, with a longer leaf through paper reports to find the data
nugget of information about insurance claims, they need. Instead, they browse insurance data
premiums, or payments buried in them somewhere. posted on NFIP’s BureauNet intranet site, select just
Bill Barton and Mike Miles don’t claim to be the information they want to see, and get an on-
able to do anything about the weather, but the screen report or download the data as a spreadsheet.

M04_SHAR9209_10_PIE_C04.indd 174 1/25/14 7:34 AM