[Project Name]
Reporting Approach
Document Overview
Prepared By:
Prepared For:
Date Created:
Last Updated:
RASCI Alignment
(R)esponsible
(A)uthority
(S)upport:
(C)onsult:
(I)nform:
PROJECT REPORTING APPROACH
GRANTSXPRESS
Revision Log
Date
Version Change
Reference
Author
Page 2 of 11
Reviewed by
PROJECT REPORTING APPROACH
GRANTSXPRESS
Table of Contents
Revision Log ...................................................................... Error! No bookmark name given.
Table of Contents .............................................................. Error! No bookmark name given.
1.
Purpose ...................................................................... Error! No bookmark name given.
2.
Background ................................................................ Error! No bookmark name given.
3.
Reporting Types and Users ...................................... Error! No bookmark name given.
3.1. Reporting Types .......................................................Error! No bookmark name given.
3.2. User Types ...............................................................Error! No bookmark name given.
3.3. Reporting and Users for this Project .........................Error! No bookmark name given.
4.
Reporting Options ..................................................... Error! No bookmark name given.
5.
Recommended Reporting Approach ....................... Error! No bookmark name given.
Page 3 of 11
PROJECT REPORTING APPROACH
1.
GRANTSXPRESS
Purpose
The purpose of this document is to define a reporting approach for the named
project/rollout.
Portions of this document will be drafted during the initial Discovery phase in order to
establish options for reporting, which in turn will help determine next steps to define a
particular approach during Plan/Analyze, as well as types of reporting team/resources
needed to support the project. Once the project is approved, during Plan/Analyze
additional information about requirements and the scope of the project will be
established, which will support defining the reporting approach, specifics on reporting
resources, and a planned schedule for implementation.
The challenges faced by units across the University drive the need to facilitate improved
decision-making through the continued development and enhancement of reporting
systems. As new administrative systems are implemented to support business process
improvement, related administrative data must be made available to appropriate
individuals to support effective use of the system, the business processes it supports,
and operational and management related decision-making.
A reporting strategy outlines a common way to deliver reporting and decision support
solutions from a variety of information systems to a variety of audiences. It is
implemented through common development methods and delivery tools, and access
policies and procedures. A reporting strategy supports data custodians and user
audiences across an institution – those who manage and use data to support various
purposes and perspectives.
The definition and adoption of a reporting approach for GrantsXpress will help to ensure
that the reporting needs of GrantsXpress users will be addressed appropriately, and in a
manner that links to a broader institutional reporting strategy such that, over time, the
University’s decision support methods and systems are integrated, collaborative, and
consistent.
Page 4 of 11
PROJECT REPORTING APPROACH
2.
GRANTSXPRESS
Background
Describe the general background for considering reporting on the project, e.g. business
drivers for reporting, data sources/applications involved, etc.
GrantsXpress is the first phase of a broader project to implement electronic research
administration at the University. The overall business objectives of the project are:







Reduce administrative burden on faculty and staff who prepare, review, & approve
grant applications
Provide necessary proposal & award data for PI, unit, & institutional management,
serving as the single source for proposal & award data
Maintain a balance between minimum requirements needed to submit an application
& desire for increased institutional decision data
Maintain a balance between unit flexibility & institutional consistency with ease of use
being the prevailing criterion
Ensure process improvement based on best practices from leading universities
Improve standard & ad hoc reporting capabilities & provide increased decision
making capabilities
Provide cross department/cross divisional reporting
GrantsXpress represents Click Commerce’s expedited deployment process. This phase
is limited to the identification of funding opportunities and the preparation, routing,
approvals, and electronic system to system submission of SF424 forms to Grants.gov.
TRACS will remain the system of record until the Full Grants phase is delivered, and
data from GrantsXpress will be entered and maintained in TRACS. Thus system of
record reporting will continue to be delivered through TRACS.
Of note are several exclusions from GrantsXpress which include non-Federal proposal
opportunities, online budget development, less than 100% of SF424 submission, and no
information and status post-submission. In addition, because GrantsXpress is indicated
as a quick win for grant administrators in particular, the timing of the phase is particularly
short, less than six months in total.
The drivers for the GrantsXpress implementation are business process efficiency
through workflow and electronic submission. Resulting reporting needs relate to
workflow management by the central offices tracking and approving proposal
submissions, and departments managing their own proposal submissions.
The need for analytic and trend reporting on proposals remain high, both in the
academic units and central offices. However, the scope of GrantsXpress describes a
limited data set that is insufficient to answer analytic questions. This type of reporting
will thus need to be deferred until the Full Grants when the exclusions noted above will
be addressed, providing a data set for proposal submission and award tracking that is
more complete to support analytic and trend reporting.
Page 5 of 11
PROJECT REPORTING APPROACH
3.
GRANTSXPRESS
Reporting Types and Users
Data access and reporting tend to be viewed along two primary axes – the type of user
needing access to information and the type of reporting they require. The reporting
approach needs to establish methods of accessing data that support each type of user
needs.
Determining the types of users to be served will help define the approach to designing,
phasing, and implementing reporting deliverables. Each constituency requires particular
types of data access and reporting.
The demand for data from transaction and warehouse systems has increased as
analysis and management of administrative operations has become ever more complex
at the University of Chicago. Reporting projects and deliverables have struggled to meet
user needs, in some cases falling short because of a lack of common definitions and
approaches for various types of reporting users and their needs.
3.1. Reporting Types
Five primary types of reporting will be needed by the University, including: Production
Reporting, End-User Ad-Hoc Reporting, Compliance Reporting, Pre-defined Reporting,
and Analytical Reporting.
Production Reporting – Reporting systems must be able to produce the operational
reports to track the University's business. This type of reporting usually indicates the
high-volume production of reports created from the operational transaction system.
Often, these types of reports are real-time, reflecting data as updated in the source
system. Production reports may also represent a snapshot or periodicity related to the
University’s business cycle, e.g. fiscal month close. These reports may be complex and
difficult to generate, thus requiring a complex programming tool such as COBOL or
Crystal, or straight SQL. Business Objects may be used to produce these complex
reports. Regardless of the tool, production reports require the technical resources of the
project team for development and maintenance.
Ad-Hoc Reporting - Ad-Hoc reporting refers to the on-demand creation of reports for
individual users or small groups. Performing ad-hoc directly against the production
system may not be recommended for broad use, as the design of the operational system
is not optimized for reporting. This affects the performance of reports for the user which
in turn impacts others using the operational system, as a contention for system
resources may result. The majority of ad-hoc reporting should be performed in a data
warehouse/Business Objects environment established and maintained by DW/BI
reporting resources on the project team. In some cases, ad-hoc reporting may be
performed against a copy of the production system. While this resolves the issue of adhoc reporting users affecting production system performance, users may eventually find
the reporting services insufficient, again because the production system data structures
and tables are not designed for reporting.
Page 6 of 11
PROJECT REPORTING APPROACH
GRANTSXPRESS
Compliance Reporting – Compliance reports include delivered production reports such
as the W-2 and other tax reports, State- or Federal-required reports, or reports for other
external constituents. Compliance reports, such as IPEDs, ARRA, and student-related
surveys. Some of these reports may be delivered or customized through the production
system, but many will need to be developed by project reporting resources to ensure
consistency with previous reporting practices. Many of these reports may be supported
by a data warehouse/Business Objects environment.
Pre-Defined Reports – Pre-defined reports are queries/reports that enable a broad
array of users to access data to answer common business questions quickly and
efficiently. These reports tend to be parameter-driven and may include navigation/links
or drill-down from summary to detailed data. A subset of these reports may be delivered
by the operational system to support business process operations or workflow
management. But as with ad-hoc reporting, a more comprehensive set of
canned/prompted reports should be delivered via the web through a data warehouse
with a Business Objects InfoView interface or University web portal. Pre-defined reports
should be developed and delivered by project reporting resources.
Analytical Reporting - Analytical Reporting is critical for management and decisionmaking. This type of reporting performs sophisticated data analysis (slice, dice, pivot
and drill-down) on data, and supports trend and longitudinal studies. Analytic reporting
should be developed by project reporting resources using a data warehouse/Business
Objects environment.
3.2. User Types
The role of the users can be defined based on their activities and responsibilities, and
include Developers, Executive Users, Information Analysts, Report Users, and Report
Viewers.
Developers – This group creates complex production, analytic, and pre-defined
reporting. They will also be responsible for the upkeep of reporting metadata and some
security.
Executive Users – Users in this category will generally be AVP’s, Deans, Chairs,
Directors, their senior administrative staff, and faculty. Reporting needs include access
to high level data analytics, and some compliance reports. Ideally these users are
served by visual dashboards with business driven metrics or KPI’s.
Information Analysts - Users in this category may use the production application
system as part of their job responsibilities, such as to perform oversight or approvals.
They are often department, dean, and central office administrators who may be
responsible for overseeing the entry and quality of data into the production application
system. These users require some delivered production and pre-defined reports, but
also need to develop their own ad-hoc reports.
Report Users - Users in this category typically use the production application as
Page 7 of 11
PROJECT REPORTING APPROACH
GRANTSXPRESS
a part of their regular job duties, which often involve operational responsibility for a
business process in their area. Reporting needs include access to online production
reports for inquiry and basic production reports. Some of these users may also need to
run pre-defined reports to track and manage their business process operations.
Report Viewers –These are report users who have a periodic need to refresh
production reports and in some cases canned, pre-defined queries to track, reconcile,
and manage. They are casual reporting users that may span the University
organization.
3.3. Reporting and Users for this Project
GrantsXpress will be rolled out to a user base of approximately 150 core users that
include URA managers to receive, approve, and track proposal submissions, and
department grant administrators to create, route, and view proposals.
With the limited scope of this project in mind, reporting needs have been articulated by
representatives of the user groups noted above. Reporting will generally fall into two
categories of production reporting and pre-defined queries, which best meet the
workflow management and status tracking needs of the GrantsXpress phase.
Page 8 of 11
PROJECT REPORTING APPROACH
4.
GRANTSXPRESS
Reporting Options
This section describes reporting options for the project, including advantages, issues,
and limiting factors. Options generally fall into one or more of the following categories:
1. Canned reports available as part of the application system
2. Tool for customized reporting, available as part of the application system or
recommended for licensing by the application vendor
3. Custom programming to create or customize reports in the application system
4. DW/BI approach and deliverables
5. Other
During ERA vendor demonstrations of Summer 2008, Click Commerce marketed
their standard reporting solution, and showed a reports tab with dozens of canned
reports they indicated could be developed out of the box, and with no significant
performance impact on the live production system. Click representatives did not
sufficiently acknowledge the role of a more robust, data-warehouse driven solution.
Since that time, undoubtedly driven by the actual experience of their clients, they
have not only acknowledged the need to extract data from the source system to build
reporting, but have indicated that the Click reporting tool, Custom Search, is limited.
In addition, while a list of sample reports developed using Custom Search is provided
on the starter site, each institution’s GrantsXpress system is custom configured and
built to specification. Thus, needed reports are indeed custom searches that must
be spec’d, built, and tested based on the GrantsXpress system that we build at the
University.
Based on experience with other vendor application systems and similar claims about
reporting from the production system, the reporting team was sceptical about
standard reporting from any ERA system. We contacted several peers including
Northwestern University, University of Michigan, and OSU. Despite the reporting
available from ERA vendors such as Click, few of these peers heavily utilize vendor
reporting, relying more on a more time-consuming and resource-intensive effort to
build their own reporting using data warehousing/business intelligence methods and
tools. These peers confirmed that building reporting outside of the production
system supports custom reporting requirements, cross-system reporting, and
toolsets that many users are already familiar with (e.g. Business Objects).
The data warehouse effort is not without its issues, however. While Click does not
impose restrictions on extracting data from the system to populate a data warehouse
for reporting, we may find limitations in our use of current University extract
standards and technologies. Click’s data is structured such that it may be difficult to
extract and ‘decode’; Click recommends use of their own proprietary tool, YA Loader,
Page 9 of 11
PROJECT REPORTING APPROACH
GRANTSXPRESS
which some peers have indicated is slow. The new 5.6 version may enable us to
use our own tools more easily for data extraction, however, the reporting team will
still need to investigate any limitations.
In addition, the reporting effort will rely on extensive forensic analysis of data to
support user requirements. Accessing the underlying database and table structures
to facilitate data modelling and source to target mapping efforts that represent critical
tasks in the data warehouse development will pose an additional challenge with
Click. No transaction system data model is provided by the vendor. The reporting
team analysts will have to develop a detailed understanding of the application
system, including business rules and how fields on the transaction screens map to
the database. In addition, a strong synergy between the application implementation
team (both functional and technical) and the reporting team will be required
throughout the project because the interactions between the functional application,
the technical build of the application, and reporting are highly intertwined.
The above factors translate to a more robust reporting effort and set of resources
required to deliver the type of production, ad-hoc, compliance, pre-defined, and
analytic reporting expected as a result of the full rollout of the ERA system.
Page 10 of 11
PROJECT REPORTING APPROACH
5.
GRANTSXPRESS
Recommended Reporting Approach
Based on business drivers, user needs, reporting options, and limiting factors, outline
the reporting approach for the project
For GrantsXpress, reporting is needed to manage workflow processes and to track
proposal submissions. Operational reports could be developed and implemented
through a data warehouse, but the refresh rate would need to be near real-time for some
of these reports, which is a significant effort within the timeframe allocated for the
GrantsXpress rollout.
In addition, as noted, analytics related to proposal submissions and post-submission
tracking are best answered once the Full Grants implementation is in place, otherwise
answers to these questions will not include large chunks of proposals (non-NIH), and
post-submission tracking, neither of which is captured in GrantsXpress.
Thus for GrantsXpress, we have noted a very limited scope and timeframe, neither of
which supports rolling out robust reporting using a data warehouse solution with
Business Objects as the user reporting tool.
GrantsXpress reporting will generally fall into two categories, the first of which is
production reporting, which in this case represents lookup views that will developed and
supported by the application team as part of the Click user workspace configuration.
The second is pre-defined or canned queries to support tracking of proposals through
the submission process. A limited set of deliverables will be built and supported using
the Custom Search tool, for use by URA managers and unit administrators. As reports
are built, tested, and rolled out, significant attention will be given to performance tuning.
Some of these deliverables will be replaced and improved in the Full Grants phase,
when user needs will drive the need for a data warehouse solution.
Page 11 of 11