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