Integrated Systems Project
ISP HomeWhat is ISP?ISP NewsThe PhasesThe TimelineThe Archives
 
 

ISP News
March 7, 2000

ISP Positions Posted
There are new openings for additional Finance Phase 1 team members, an instructional designer, and a technical track team lead. These positions will be part of a combined purchasing/accounts payable and order entry/inventory team for the Integrated Systems Project. The new positions have been posted to the Human Resources ISP job website (http://www.hrs.virginia.edu/ispjobs.html). If you are interested in any of these positions or know of someone who might be, please check out the website. The team will begin its work on April 1, so the positions must be filled quickly.


New Phasing for Better Roll Out

As we have progressed in the finance phase of the Integrated Systems Project and explored more fully our current processes and Oracle's functionality, it has become clear that an adjustment to our planned deployment order of the Oracle applications would present a more optimal product to the University community. In particular, we discovered that implementing the Purchasing/Accounts Payable application in a second finance phase would cause significant inconvenience, training difficulty, and throw-away work as we tried to temporarily modify our CAPPS system to make it compatible with the new Oracle system. The decision to go Project Centric made re-phasing even more necessary since it would be virtually impossible for CAPPS to accept the new account code structure (the PTAEO) and pass it through into the Oracle applications. As noted in the last ISP Bulletin, the PTAEO is an acronym for the five segments (project, task, award, expenditure type, organization) required for recording transactions in a Project Centric environment.

As a result, the ISP Executive Committee has approved a re-phasing of the project that will provide the University with a more "whole" system at the end of the first deployment, while retaining the overall five-year project timeframe. A comparison between the original and the new phases follows:

Original Phase 1A: New Phase 1:
General Ledger with Journal Entries General Ledger with Journal Entries
Funds Management Funds Management
Labor Distribution Labor Distribution
Accounts Receivable and Cash Management Accounts Receivable and Cash Management
Reports and Data Warehouse Reports and Data Warehouse
Required functionality for Budget, Training Administration and Human Resources Required functionality for Budget and Human Resources
Check Writer (FASD) Accounts Payable (Added from Phase 1B)
Purchasing (Added from Phase 1B)
Order Entry/ Inventory (Added from Phase 1B)
12-15 months 19 months


Original Phase 1B: Delete Phase:
Accounts Payable
Purchase Order
Public Sector Budgets
Pre-award Grants
Fixed Assets
Order Entry/Inventory
Reports and Data Warehouse
9-12 months 0 months


Original Phase 2: New Phase 2:
Human Resources Human Resources
Payroll Payroll
Time Management Time Management
Training Administration Training Administration
Reports and Data Warehouse Reports and Data Warehouse
Pre-award Grants (Added from Phase 1B)
Public Sector Budgeting (Added from Phase 1B)
Fixed Assets (Added from Phase 1B)
12 months 12 months


Original Phase 3: Same Phase 3:
Student Systems Student Systems
18 months 18 months


The benefits of the new phasing are numerous, while the negatives can be minimized.

Pros:
-Whole system delivered on day 1
-Consistent functionality for users: There will be consistent charging instructions and fewer interfaces.
-Deployed at beginning of FY: This will reduce the amount of data requiring conversion.
-Deploy better version of software: There will be a greater likelihood that a newer version of the software and Oracle Warehouse Builder will be available for the first deployment.
-Longer phase: This will allow more time in first effort to deploy a quality product and more reaction time for internal service providers and vendors to alter their systems to accommodate the new charging instructions (PTAEO).
-Less throwaway work: There will be far less need for temporary technical interface work.
-Testing time: Testing will be devoted to making new system work, not to making old systems work with new ones.
-3 rather than 4 deployments
-Budgets and Pre-Award Grants delayed: Delaying the implementation of these two applications enhances the possibility that these new products will be installed at other higher ed institutions first.

Cons:
-Number of applications deployed on day 1: While more product will be deployed, the fact that we will be deploying a whole system will be less confusing to users.
-Number of users requiring training: While many more users will require training for the first deployment, there could be a reduction overall, since we will be training once as opposed to twice for phases 1a and 1b.

As Leonard Sandridge, the University's chief operating officer, notes, "The Integrated Systems Project was designed to be flexible. To meet the challenges of delivering an integrated system to the entire University community, we must adapt as situations change and circumstances dictate. By combining phases 1A and 1B, we eliminate awkward short-term measures and offer more users early access to the new system. This effort will present a challenge, but I am confident we will handle it successfully."


How Goes the Chart of Accounts
One of the major tasks of universities implementing an enterprise resource planning (ERP) system is redesigning the chart of accounts. Currently, the U.Va. chart of accounts has two main (visible) components - the account code and the object code. The Oracle General Ledger application will provide the opportunity for more segments, which will enhance reporting capabilities. Thus, the General Ledger team has been consulting with ISP advisors, the ISP Executive Committee, and other universities that have redesigned their charts of accounts using Oracle applications, and a consensus is emerging on how it might look.

The proposed segments, which will be tested over the next month to determine how well they might meet the University's reporting needs, include:

-Entity - This is the balancing segment of the chart of accounts that houses total credits and debits. It is the highest level of financial reporting and, for initial purposes, will include the Academic Division and U.Va. at Wise.
-Natural Account - This is what we now call an object code. -Organization - This is the specific area of responsible for a financial transaction and will generally mirror the University's organizational chart.
-Project - This segment links directly to the Project segment of the PTAEO in Funds Management and will track financial data by type of activity or line of business.
-Fund Source - This is what we now call an account code.
-Purpose - This is similar to the current state program code and addresses the general use of resources, such as instruction, research, public service, and academic support. This reporting requirement may be a segment in the chart of accounts or may be an attribute housed in the PTAEO.
-Future - This segment would be held for future expansion of the chart of accounts to fulfill new requirements. In the meantime, it would default to zeros. These segments would map to the PTAEO as follows:
-Project --> Project (P)
-Fund Source --> Award (A)
-Natural Account --> Expenditure Type (E)
-Organization --> Organization (0)
-Task (T) in the PTAEO is a level of detail not required for the chart of accounts.

A final decision regarding the future segments of the University's chart of accounts will be made within the next several weeks, after testing and after key stakeholders have had a chance to review the results of the testing. Then begins the work of deciding the actual contents and values within each segment of the new chart of accounts.

Human Resources Involvement Central to Oracle Implementation
Human Resources is a key player in an ERP (Enterprise Resource Planning) implementation. Employees' responsibilities and roles may change, they may have to acquire different skills, and there are change management issues that are best addressed by human resources professionals.

In the case of an Oracle implementation, Human Resources is doubly important. The integrated system is dependent on information set up in the HR tables. Any one who is authorized to use any of the Oracle applications must be listed in the HR tables, regardless of whether or not they are paid by the University. In addition, every person's role is defined in terms of what application(s) they have access to and what they are authorized to do within each application. "What you will see in the morning when you turn on your computer is dependent on what roles and responsibilities have been set up for you in the HR tables," says Barbara Henry, director of the Human Resources Management System, who works part time with the ISP. "That is why it is particularly important that they be set up right the first time."

Recognizing the centrality of HR in the ISP effort, several people from University Human Resources and ITC are devoting time to the project. In addition to Henry, Tom Gausvik, chief human resources officer, Debbie Deane, HR systems analyst, and Diane Mundell, manager of HR/payroll systems for ITC, are working on HR table set up issues. A working group is also being assembled to address human resources management issues.

Functional Teams Move on to Gap analysis

The ISP functional teams have completed defining future business models at a conceptual level. The processes were reviewed by groups of people from the University community who are considered stakeholders in the processes. These reviewers were asked to look for "show-stoppers," anything to indicate that the teams are missing something important or proposing something unworkable. While issues were raised, all appear to be resolvable. The teams have moved on to identifying potential gaps between those processes and the functionality of the Oracle applications and possible solutions to identified gaps.

"When it comes to finding a meeting place between what we now do and what Oracle allows us to do, we will move in the direction of following Oracle's 'out-of-the-box' functionality," says Bill Randolph, project director. "Oracle incorporates 'best business practices' into its software, and any customizations will make it more difficult to upgrade when new versions become available. Clearly, if there are mandatory University requirements that Oracle absolutely cannot meet, we will figure out a way to work around it. But the bar for approving any modification to the software will be quite high."

Technical Team Working on Parallel Tracks
The ISP technical teams continue to work on parallel tracks, upgrading hardware and anticipating the need for interfaces and data conversion down the road. On the first track, the team installed a hardware upgrade that will meet all of the project's development needs. An RFP will soon be ready for hardware to support production.

On the second track, another RFP is in the works for an interface and conversion tool. Team members continue to identify, catalog, and evaluate needs for interfaces and conversions. In addition, they are meeting with departments with existing systems that will have to be changed to accept PTAEOs if those systems are not replaced by Oracle in the first phase. Examples include the University Bookstore, Facilities Management, Housing, and the University Press.

See Team Links for Team Status Reports
Detailed updates on the teams' work are now on the ISP website. Link to the team that interests you, and scroll down to "Status."

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

 

"By combining phases 1A and 1B, we eliminate awkward short-term measures and offer more users early access to the new system."

Leonard Sandridge,
U.Va. COO

 
 
ISP HomeWhat is ISP?ISP NewsThe PhasesThe TimelineThe Archives
 
2001 by the Rector and Visitors of the University of Virginia
Thursday, 22-May-2003 14:30:57 EDT
U.Va. Home Page Website Index U.Va. Map Calendar People/Web Search