ISP News
May 2, 2000

Biology is Biology is Biology
It's nice 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 different purposes.

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.

On 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 information.
     "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."

Making 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.

Countdown 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."

What 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.

ISP NEWS FROM OTHER PUBLICATIONS
Inside UVA	February 4, 2000	Teams get to work on bringing new integrated systems to U.Va.

Go to ARCHIVED ISP NEWS DIRECTORY