May 2, 2000
is Biology is Biology
to have nicknames and terms of endearment, but imagine if you had four
legal identities! That is the case for many units in the University because
our administrative systems evolved along separate paths. Departments now
have as many as four codes by which they are identified: home department
code (which will continue to live on in the current human resources system
until Phase 2), executive level code, major budget unit code, and department
code. One of the virtues of our new integrated
system will be the assignment of one code to each unit, or "ORG," that
will be shared throughout all applications. The ORG designation will track
to the Organization segment of the General Ledger as well as the O segment
of the PTAEO.
"The new ORG structure will incorporate a hierarchical roll-up, or parent-child
relationships between and among all the University units," says Bill Randolph,
project director. "For example, the Dean's Office in the College of Arts
and Sciences is parent to the Biology Department, but child to the Vice
President and Provost, which, in turn, is child to the Office of the President."
Structuring the ORG chart for the University
is central to the Oracle system and is emblematic of the "best practices"
embedded in an integrated system. The ORG structure created in the Oracle
applications will be close, but not identical, to the University's published
organization chart. That is because these two structures serve slightly
Feedback Form Now on Web
We have added a feedback
form to our website so you can send us your comments. You can link to
it from the yellow bar on the home page.
to Gap Court
After the General Ledger, Magic (Funds Management and Labor Distribution)
and Accounts Receivable/Cash Management teams finished consulting with
members of the University community last month, each team anxiously took
lists of approximately 200 business requirements per application back
to their war rooms to analyze whether or not Oracle functionality would
meet each need. To their considerable relief and expectation, the Oracle
applications do provide virtually complete functionality. What gaps exist
are primarily in how Oracle provides information resulting from business
transactions versus how the University or State or granting agencies require
"These reporting gaps are common because of the
individual reporting needs of different institutions," says Dick Gross,
KPMG functional lead for the project. "Addressing these gaps does not
require any customization to the applications themselves."
The lists of gaps were presented before "Gap
Court," where each was prioritized or returned for further research. Tentative
resolutions were also proposed. "In some cases, the identified requirements
that are considered gaps relate to the way we currently do business, but
may not be requirements in the future environment," says Bill Randolph.
"In others that are designated lower priority, the resolutions may have
to wait until future phases. But certainly all critical gaps will be addressed,
and fortunately there is not a great number of those."
a List and Checking It Twice
The interface and data conversion list has been viewed and reviewed
and is now available for another look through our website under Document
Repository in the Archives section. While the Technical Team has moved
on to estimating the time and resources it will take to build the interfaces
and conversions, the door is always open to those who identify any that
may have been missed. The team is also currently mapping each step required
to accomplish each interface and conversion.
on the Chart of Accounts and PTAEO
This is the month when all questions must be answered about the segments
of the Chart of Accounts and PTAEO.
How long will each segment be, and what values will they contain? How
will they be housed in each application, and how will they be presented
to the user? Marathon sessions are underway to settle these issues so
that system set-up can proceed.
"We are definitely past the conceptual stage,"
says Shy Hicks, General Ledger team lead. "This is the first concrete
step to make the Oracle system a U.Va. system."
is a Working Prototype?
The final stage in the design phase of the finance implementation is to
develop a working prototype. The teams are beginning that process, which
will end on July 31, 2000. Prototyping is based
on the idea of developing an initial, mock implementation for user feedback,
and then refining this prototype through many versions until a satisfactory
system emerges. In practical terms, it means setting parameters on which
of Oracle's many different functions the University wants to utilize,
selecting which business processes to prototype in each module, completing
required set-up steps, entering a set of records through which to run
the transactions, running the transactions, and validating that they work,
first within the application and then between applications.
Subject matter experts will be consulted throughout
the prototype process to validate that the proposed approach to each process
works for the users. The end result will be a design ready to hand over
to the Technical Team to begin the build phase.
to ARCHIVED ISP NEWS DIRECTORY
of the virtues of our new integrated system will be the the assignment
of one code to each unit, or 'ORG,' that will be shared throughout