Return to the
Integrated Systems Project Home Page
Integrated Systems Task
Study Group #2
Integrated Systems Task Force Study
Group #2 was charged with the following mission:
To develop a list of critical
features that a purchased product must have before it can be
considered a viable candidate for replacement of the following core
applications: Financial, Student, Human Resources and
The Study Group was comprised of
individuals who hold primary responsibility for the major core
systems at the University. Through this responsibility, these
individuals are considered both the stewards and functional experts
of these systems. The study group members are as follows:
Jay Scott (leader) - Budget
Shelley Payne (facilitator) -
Organizational Development and Training
Nancy Rogers (scribe) -
Ann Antrobus - Registrar's
Julian Bivins -
Jack Blackburn -
Glenn Fielding - Medical Center
Tom Gausvik - Human
Larry Groves -
Dolores Hildebrand - Purchasing
and Materials Services
Bernie Hill -
Yvonne Hubbard - Financial
Jeanne Inge - Purchasing and
Steve Kimata - Bursar's
Jim Paul (until his departure)
- Medical Center Computing
Shirley Payne -
Larry Simpson - Office of
Career Planning and Placement
Ken Sinarski - Financial
George Stovall - Institutional
Assessment and Studies
Matt Waldron - Medical Center
The Study Group undertook a
multiphased approach to the development of this list of requirements.
The first phase involved the collection of a list of "must haves"
from the perspective of the stewards of the systems. Each member of
the group consulted with their respective areas and compiled a list
of 25 high level requirements that they felt any replacement system
would need to have in order for the implementation to be
The second phase involved
participating in focus groups that were held with the end users or
customers of the various systems. In order to minimize the time
burden on the participants, these were held in conjunction with Study
Group #1. Study Group #2 members who participated in the focus groups
were able to obtain additional critical requirements as defined by
the end users/customers of the systems and incorporate these
requirements into this document.
The third and final phase of the data
collection took place through the review of data submitted by members
of Study Group #1 regarding their thoughts on critical features
required of any replacement system. Upon completion of all three
phases, the members of Study Group #2 consolidated all of the
information that they had collected and present it below as a final
report to the Integrated Systems Task Force.
Critical Features for the University and any
Throughout the deliberations of Study Group #2, one overriding
concern continually surfaced - that the University of Virginia not
lose sight of the reputation it has earned over the past many years
of being the number one public institution in the country. It was
strongly voiced by all present that this ranking was not an
accidental one, but one that had been preserved by those stewards of
the institution, both academic and administrative, who have placed
the interests of the University in the highest regard. These stewards
include, but are not limited to, the members of the Board of
Visitors, our learned faculty, our academic deans, the Senior
Cabinet, and the administrators of systems.
It has long been evident that the University is driven by the
needs of our faculty and students, and that administrative tools
(generally described as our systems) are implemented to satisfy those
needs. We ask the decision-makers to continue to give credence to
this philosophy as they wrestle with the issues inherent with a
purchased, integrated system. For if we subjugate the unique and
diverse needs of our faculty and students to the pursuit of
technology, do we risk losing that which has made the University
The paramount concept that must be preserved throughout the
evaluation, decision and selection processes is that any system(s)
which the University acquires and implements should support the
mission and values of the University. Although changes in business
processes may be precipitated by this initiative, the acquisition of
new administrative systems should not be the driving force behind
major shifts in the University's management philosophy. Preserving
the University's decentralized management structure can be
accomplished through the proper identification and replacement of the
core administrative systems with systems that are designed to provide
integration while supporting the varied shadow systems in the field.
Once properly defining the scope of what is truly a core system has
been accomplished, then the selection and implementation process can
In order to select an appropriate administrative system for the
University, certain requirements will have to be met. Not only is it
important to generate a set of critical requirements that are
necessary of an integrated system and its vendor in order for it to
be acceptable to the University, but it is also vital that the
members of the University community develop and support a set of
requirements placed on the community itself. Without this second set
of requirements, any integrated system is likely to fail.
- The entire University community, as well as systems caretakers
(ITC and stewards) and users/customers, must adopt a spirit of
cooperation and compromise if an integrated system is to have any
hope of succeeding.
- Stakeholders must be willing to accept some system features
which may not be ideal, or in some cases might even be less
desirable than features of the current system, in order to reap
the overall benefits which an integrated system can provide. The
overall project benefits to the institution must be defined in
order that the units can see what benefit is derived from the
sacrifices they may need to make on a local level.
- In some cases, administrators (both central and unit) must be
willing to change the way they do business to accommodate the
integrated system. Can we have an integrated system if a large
unit says that they won't participate?
- In order to insure an efficient, effective, and compact set of
integrated data elements, system caretakers must compromise with
each other when developing data definitions across systems. It may
be necessary to appoint a "steward" for each data element.
- A formal procedure should be developed for resolving conflicts
between users and caretakers of different systems, particularly in
cases where the conflict crosses vice presidential lines. All
system caretakers, as well as the vice presidents, must support
the procedure and abide by the results.
- The process of implementing new systems and reengineering
business practices could result in the elimination of positions
and/or the redefinition of job duties. A formal plan of dealing
with these types of changes will need to be an integral part of
- Once the scope of the project has been defined, it is
essential that as many of the stakeholders as possible are
included in the final decision. This will minimize resistance to
conversion at a point in the process that is beyond the point of
- This project should be marketed as a University wide project
and not just an administrative systems project. It will impact all
areas of the University and communication with, as well as input
from, the University at large needs to be an integral part of the
selection and implementation.
- The new system must meet all
existing mandatory, regulatory, and cost beneficial system
requirements unless changed by the appropriate level of
- It must be flexible and provide
simple methods for modifying functionality to quickly meet the
requirements of both administrative and academic
- It must provide a link to third
party desktop software for calculations, decision support,
graphics, and report presentation or allow for simple download of
raw data in standard format for use in shadow systems.
- It must have an acceptable
interface with ITC's security system (currently Top Secret),
integrate with ITC's security strategy (file security and
application security) and have an end product that allows for a
single login ID and password for all applications.
- It must provide on-line,
real-time windows based data entry and system update for all
functions of the system across all subsystems. It must selectively
allow view-only access in addition to view and update access as
well as concurrent batch updating.
- It must interface with existing
systems (e.g. FAS, Accounts Payable, OSP, Property Accounting,
Facilities Management, GL for account validation, HR, Payroll and
ISIS, Materials Management and Stores, and required State systems)
until the integrated modules replace them. This interface must
allow for cross referencing that will identify potential conflicts
- It must have pull down screens
for data validation and help, error messages, various search
features and ability to attach notes to transactions.
- It must allow for data entry via
the World Wide Web and must support future web applications, such
as UVA's electronic forms.
- It must provide for batch
submission of data, such as user-generated data from SAS programs
- It must allow authorization
routing with multiple approval levels within and outside the
- It must allow inquiries on
transactions which are in progress and on-line notification of
completed transactions with the ability to see comments of persons
involved in the process.
- It must interface with the
University's electronic mail and telephone communications
- Security must be on a data
element basis, controlling view and update capabilities. This
security should provide protection against unauthorized access
while giving users the ability to easily access the data (for view
and download) to which they have a legitimate need for
- It must interface with the
University's Information Warehouse, currently on a SYBASE
platform, or provide an information warehouse module that allows
for migration of our current data to the new system.
- It must provide simple methods
for modifying screens, data tables and standard
- It must have security which is
easy to maintain but protects the integrity of the system - using
security access by level as assigned to a user ID vs. security
- It must require minimal hardware
requirements -- accessible by all platforms (UNIX, PC and
- It must have an infrastructure
which will accommodate massive usage of the system without
affecting response time.
- It must provide general access to
general routines and abilities that facilitate added custom
development by the University e.g. the adding of new data and new
screens and the ability to change existing screens without
substantial impact to ongoing support.
- It must provide for edit and
reasonability checks for online and batch
- It must accommodate future dated
transactions in an online user accessible file that is easy to
maintain and update.
- It must accommodate existing
processes and management reporting requirements as defined by DPT,
DOA, DPB as well as those of the federal government.
- It must integrate A/P, Payroll
and Student systems with our Non-resident Alien Tracking System
(ALIEN) in order to provide tracking of payments, tax withholding,
treaty benefits, and other information necessary for reporting
purposes or provide such a system.
- It must accommodate non-12 pay
schedule and escrow of benefits (e.g., faculty who work and are
paid over 9 or 10 months but whose benefits are paid over 12
months) and employees who are on variable length work schedules
(flexible staffing model).
- It must provide adequate audit
trails or audit reports for all transactions.
- Selected firm must provide
ongoing maintenance and support for the system software. The
support may be by telephone, electronic mail, or on-line problem
resolution with the ability to download program updates and other
- It must allow data access from
multiple workstations simultaneously. Number to be predetermined
prior to purchase of new system.
- Any new implementation must
include easy access to training from people who know the system
and the University processes well.
- The implementation of a new
system may reduce accessibility for the end users as the core
system technology outpaces the departmental technology. The
implementation may require significant upgrades of local equipment
in the units. This represents a significant cost and these
financial concerns must be addressed as part of the implementation
- It must be user friendly, e.g.,
pull down menus, point and click fields, ability to produce a hard
copy of any given screen; allow for general ease of navigation;
clarity of use; ability to logically group screens by function to
minimize menu levels; easily move among modules; ability to leave
screen and return to it without losing data partly keyed; provide
user defined on-line help at the field level; provide values of
fields, customize screen sequence.
- It must be table
- It must allow for authorization
routing of transactions with multiple levels (from departments to
central offices) i.e., user-defined and/or predefined routing for
individual transaction types, notification of routing to an
alternate person, if approval is not complete by a specified time;
support electronic signatures.
- It must be easy to maintain,
modify and enhance.
- It must reduce paper processes
and improve document management via document image processing and
optical character recognition.
A new student information system must
integrate the functions of the billing and receivables process (which
includes student tuition, fees, dining, housing and other expenses)
with student admissions (graduate, professional, and undergraduate),
financial aid (federal, state, and institutional), and student
registration data (including biographical data, course data, grades,
degrees, and other academic achievements).
- It must interface with all
financial aid packages such as PARS and INAS. A vendor must be
able to react quickly to changing federal requirements, such as
- It must allow for data input from
outside agencies and for data transfer to external agencies.
Particular examples are receiving data from the Educational
Testing Services for standardized test score results, reporting
data to the National Student Loan Clearing House, transferring
transcripts to other institutions and agencies electronically via
SPEEDE, as well as communication with EduServ and third party
- It must interface with the human
resources system to verify faculty and student data and to monitor
College Work Study programs.
1. It must interface with or provide
comparable replacements for the Schedule25 classroom scheduling
system (Facilities Management and Provost space management system),
the PACE computer-assisted advising system (or provide another such
system acceptable to academic units), the Griffin System for
monitoring the photo identification card system and door access, and
the EPOS telephone system. The data stewards of student systems are
aware that other system replacements for these major components may
be available. Nevertheless, in the decision-making process, the cost
of replacing these components should be given high
- The grading schemes of each
resident school must be maintained unless current policy changes
- It must allow for applicants
wishing to submit application to more than one school for any
particular academic term and must accommodate the University's
Early Decision admissions process.
- It must accommodate the
University's variable and fixed tuition rate structures, including
special areas such as non-topical research, class specific
surcharges and the tuition waiver program for University
employees. It must handle various school generated awards, such as
tuition remission, tuition differential, and stipends.
- It must interface with the
University's Division of Continuing Education and provide for its
- It must work with or replace the
master locator function. This function maintains and finds
transcript data for students who attended the University from 1960
- It must provide for timely
production, and security of academic transcripts for all current
students and alumni.
- It must provide up-to-date
information to all students, parents, and alumni about the status
of admissions, bursar, financial aid and registrar
- It must be able to handle
multiple terms of financial data, provide a third party billing
module, and use estimated financial aid credits.
- It must interface with or replace
the current on-line cash registers.
- It must provide "one-stop" access
for students rather than force them to go to several locations for
- It must provide the ability to
automatically respond to e-mail inquiries from
- It must automatically load all
e-mail inquiries into the database.
- It must provide a link between
the prospective student database and the applicant
- It must provide a voice response
system for admissions that interfaces with ISIS or its
A new financial system should not
only include features necessary to maintain the current level of
service which we provide to our customers, but it should offer
enhancements which will allow the University to take advantage of
emerging technology and decentralization. The new system, while
maintaining necessary controls, would allow for greater use of EDI,
enhance reporting capabilities and data management, and allow for
electronic interchange of information among internal and external
- It must capture 1099, 1042s, and
other tax-reportable activity based on transaction activity, not
vendor. It must be able to withhold taxes for NRAs or backup
withholding for vendors. It must provide full reporting
capabilities, including printing laser documents, magnetic IRS
files, and user mailings to individuals and/or
- It must maintain transactional
and account balances to continue to meet all state requirements
for decentralization and cash management. It must allow for
Electronic Data Interchange (EDI)/Comptroller Debt Setoff (CDS)
processing, daily and monthly settlements, reconciliations, daily
appropriation/allotment/cash monitoring, and fiscal year end
closing. It must interface with state budget system
- A/P system must be able to issue
payments by check or electronically (Automated Clearing House).
All payments must be issued by due date and consolidated into one
payment per day per vendor.
- For bank reconciliation purposes,
it must provide a mechanism to allow cash balances and transaction
detail maintained at the individual account level to be aggregated
according to the University's existing bank account
- It must generate transaction
history files that contain all the direct records input/accepted
by the accounting system. It must generate records in the
transaction file for the indirect updates to cash, fund balance,
and revenue, expenditure and budget controls.
- It must use self-balancing
accounts that follow NACUBO fund accounting, user updateable
attributes that facilitate the preparation of GASB financial
statements and other national and state reports, and provide edit
controls based on flexible user controlled parameters.
- It must allow for compound
journal entries (IDT), create tables and transactions for computer
generated transactions (mechanical entry).
- It must provide integrated two
way interfacing with existing major systems (HR, ISIS, Accounts
Payable (AP)/Purchase Order (PO) Inventory Management System
(IMS), Budget) and subsystems (i.e., Physical Plant). An
integrated system-wide vendor file that restricts the capability
of creating duplicate vendors and allows the flexibility of keying
variable data to be passed or updated on a transaction type basis
(i.e., travel, foreign nationals).
- It must have enough flexibility
to provide a base account and object code structure to meet the
University's central budgeting, reporting and accounting needs
which can then be adapted on a departmental or cost center basis
to meet individual department's needs managing financial
- It must provide Electronic Data
Interchange (EDI) which offers digital interchange of IFBs,
purchase orders, acknowledgments, invoices and electronic fund
- It must provide a means to
electronically link RFPs, bid specifications and other
correspondence to POs with the use of imaging and mapping to
Microsoft Office documents.
- It must provide a means for users
to order from on-line contracts and catalogs.
- It must allow payment tolerances
to be set by purchase order type.
- It must provide a commodity based
vendor file and processes to solicit IFBs, evaluate responses,
transmit and award.
- It must be flexible in changing
orders, choosing where, how and when to print an
- It must allow the use of multiple
accounts and object codes on a single PO or line item.
- It must provide on-line means for
manager to distribute incoming requests to buyers and monitor
- It must allow Stores to sell to
other agencies such as the Medical Center.
- It must allow receipt of stock
into inventory without a PO.
- It must be able to calculate
Stores inventory levels, reorder points and order quantities
automatically with manual override capabilities and monitor
expiration dates of goods.
- It must be able to add and delete
items from inventory easily.
- It must provide an on-line
catalog of stock items and the ability to order from the catalog
- It must be able to generate and
read barcodes for receiving, delivery, inventory and tracking
purposes in Stores.
The proposed financial management
system would need to accommodate the approved future enhancements for
the processing of grants and contracts. This will probably mean
allowing for electronic transmission of information at all process
steps from P.I. submitting proposal to final billing and close-out of
project. This could mean an entirely new system for OSP. Any new
system must include the following:
- It must collect data for
quarterly reports to agencies.
- It must have an effort reporting
- It must have the ability to
compute, charge and return overhead.
- It must be able to access to cash
position for proper draw down & deposit.
- It must have the ability to
freeze an account when project end date is reached.
- It must have deficit
- It must allow for project
specific cost-sharing commitment identification.
- It must provide quarterly
None of the required features listed
below are required as the result of policy or government mandate.
However, in the process of conducting an extensive survey (over two
years ago) while developing an RFP for the purchase of a new budget
and financial management system, it was determined that the below
requirements would be necessary if we were to deliver a user friendly
time efficient system.
Budget and Financial
- It must support the preparation
of budgets at department, school and University levels by
providing a facility to build budgets from the lowest appropriate
organizational levels. The system must support summarization of
budgets at higher levels, based on user-defined
- It must support multiple versions
of budgets (e.g., original, revised, prior year original and
revised, next year, and future years).
- Data must be integrated
throughout the processes of long-range planning, budget
development, position management and financial
- It must provide the departments
and schools with the capability to submit budgets, plans, and
amendments from the workstation for review and
- It must provide the University's
Budget Office with the means to monitor the completion of the
budgets by departments and schools.
- It must support the ability to
budget multiple fund types (e.g., unrestricted and restricted;
grants, gifts and endowments).
- It must support the budgeting of
all revenues, transfers, encumbrances, and
- It must be able to access human
resources information (e.g., position status, history of position
changes, and actual payroll history). This data will be used to
support salary setting by capturing position information. It must
allow for retroactive and future-dated payroll transactions to
more accurately project and budget actual salary
- It must support the funding of a
single position from multiple sources such as state funds, local
funds, and grants. The fund split could be based on percentage of
effort or on specific dollar amounts.
- It must support concurrent
- It must allow for multiple
approvals of a single transaction (e.g., budget amendment,
interdepartmental transfer, purchase order) across school and
- It must provide the ability to
record and monitor transactions, such as purchase orders,
interdepartmental transfers, etc., as encumbrances and accordingly
reduce available budget balances.
- It must support budget variance
- It must enable a user to analyze
information at successive levels of detail.
- It must support a variety of
planning and forecasting methods using multiple bases and
- It must provide tag accounts so
that department finance managers can perform detail level
It must have the following
- It must support Section 125
- It must support defined
contribution plans and support defined benefit plans.
- It must provide automated Maximum
Exclusion Allowance computations for 403(b) plans.
- It must support unlimited
- It must use tables to determine
eligibility rules and calculation methods for both coverage and
contributions to the plans. Tables will be constructed to simplify
plan set up and future maintenance when a plan's rules
- It must support multiple health
- It must support life insurance,
short term/long term disability insurance plans, etc.
- It must support online benefit
- It must support COBRA
- It must support multiple pay
plans and premiums pay e.g. overtime, shift differential, on call,
call back, unit pays, lump sum payments, piece rate, salaried, and
- It must ensure compliance with
Federal Fair Labor Standards Act
Employee Master File
- It must allow for dual employment
e.g. multiple jobs at different rates of pay.
- It must accommodate faculty
appointments e.g. tenure dates, up to five titles, educational
- It must accommodate classified
staff processing as defined by the State (VA Personnel
- It must provide online work
history and training records of employees for a specific period of
- It must provide online
- It must deal with multiple date
fields i.e. hire date, service date, benefits date, performance
review date, etc.
- It must allow for at least 25
funding sources for a position/person.
- It must accommodate tracking of
non-pay individuals i.e. retirees, visiting faculty.
- It must accommodate existing
state constructs and support position coding for ODT, orientation
and other central administrative training purposes.
- It must accommodate multiple
employees in a single position.
- It must integrate with the
University Budget System.
- It must relate position to
employee and vice versa.
- It must support standard payroll
processing including multiple pay cycles, delayed and prospective
pay, support retroactive pay adjustments, automated special check
- Summary payroll and fringe
benefit transactions must update the Financial Information System
on a pay period basis and must be distributed by account number
and object code.
- It must support on-line payroll
history for at least one year.
- It must capture both fiscal year
and calendar year to date information for pay, employer paid
deductions, and other relevant data.
- It must provide for proper
taxation (students, foreign nationals, etc.) and deduction for all
pay, including supplemental pay. Special needs include
"departmental paid" employee deductions and the ability to "turn
off" FICA tax prior to reaching minimum earnings.
- It must support W2 preparation
including the ability to make additions to gross income for
non-payroll reimbursements (i.e. moving and relocation
reimbursements and meals) and non cash fringe
- Payroll information must be
available to complete the federal requirements for effort
reporting on a periodic basis (i.e. bi-monthly, semi-monthly,
- It must support a fully
integrated time and attendance system including leave processing
of up to 40 different leave types (unless the University is
successful in reducing this number). The system must provide leave
processing with tracking of accrual and use, on-line update and
query access, stored leave history for a predetermined number of
years, leave liability reporting, periodic warning reports, and
retroactive processing capability.
- It must incorporate a mechanism
for automatic accrual of multiple leave types (vacation, sick,
paid time off) with calculation of accruals based on pay cycle,
employee type, years of service, and maximum accrual tables, as
well as mechanism for automated reporting, accumulation, and
automatic reduction of compensatory time earned.
- It must allow for the creation of
new and innovative human resource services and programs, and
facilitate the reengineering and process simplification of
existing workflow processes
- It must reduce manual
- It must improve control
mechanisms and audit trails
- It must provide for simplified
management reporting; e.g., provide on-line inquiry (queries)
facilities for Human Resources and University (user) departments
and interface with the Information Warehouse
- It must have a high level of
system integrity and security; e.g., at data element level for
human resource and payroll data
- It must either replace or
interface with the University's On-Line Employment & Personnel
Even though the ISTF decided that
Development would not be part of the total overall analysis, as Study
Group #2 had already collected development data, we offer it here as
a supplement to our final report. Should the purchase decision come
down to two comparable vendors, this may provide some additional
Regulatory Requirements - None
- It must interface with FAS and
other financial systems and have appropriate audit
- It must be able to provide
financial reporting for the University and the Foundations in
accordance with necessary internal and external requirements (e.g.
- It must be able to support
flexible and sophisticated campaign planning and
- It must support distribution
across multiple business locations.
- It must be flexible and robust
enough to reflect the University's business procedures without
- It must allow the tailoring of
user access to various components of the application according to
- It must allow the monitoring of
campaign progress from many different aspects: by school, by
Foundation, with the ability to roll up into broad categories, as
- It must allow for the management
and tracking of major University donors, and provide reports of
these activities for subsequent review by management;
- It must facilitate the data entry
process of both gift and biographical information.
- It must have robust gift entry,
suitable for heads-down data gift processing.
- It must have capability of
interfacing with other University systems: Admissions, OSP,
Scholarships, Endowments, Purchasing - for vendor information,
VSAF's point system, etc.
- It must provide flexible ad
hoc reporting by the user community.
- It must have sophisticated Annual
Giving modules, which provide flexibility for our various schools
and divisions to tailor their individual programs.
- It must have a Special Events
module which allows for the tracking of invitations and attendees
at the various sponsored University events.
- It must have a Planned Giving
module that reflects the various instruments and methods used by
- It must have the ability to
distribute information easily to users in the University
- It must have an integrated
messaging capability, to let development officers know that
activity has taken place with a particular prospect.
This list of requirements is by no
means an all inclusive list as there are many more features that
would be "nice" to have. The above information is simply those items
that if unavailable in a new system, would create significant
hardship on the stewards and users of the system(s). It is however,
designed to be a guide for use while evaluating potential integrated
systems or best of breed selections. Study Group #2 is extremely
grateful to have been given this opportunity to contribute towards
such a significant project at the University and would be more than
happy to provide additional information if the task force would find
it helpful in making this important decision.
Site maintained by firstname.lastname@example.org
Updated January 12, 1999