BASIS Steering committee
Gerry Bomotti, Gene Buckley, Dick Cottrill, Tom Dorre, Allen Lacey,
David Martinson, Susan Unger, and Bob Zimmerman
W. David Wimberly
Colleen Briney, Bill Overby and William Rains
BASIS I and II discussion lists
BASIS September status
This report addresses both the BASIS I and BASIS II projects due to
my combined responsibilities.
Headings separate the sections addressing each project.
The "Common" section notes activities and issues related to both
I strongly favor a phased development and implementation for both
BASIS projects and will be seeking Steering Committee approval to
proceed in this direction.
Ideas for these phases are included in the project sections of this
Some of the reasons and justification for taking this approach follow:
- The BASIS systems represent a new way of conducting business on
Departments will be responsible for entering information directly into
the centralized system, department heads and managers will be
responsible for using the same systems to review and approve what has
been entered remotely, and all this information will be readily
available for inquiry directly by the departments.
The degree of change required by everyone will be major.
A phased implementation will allow us to ease into this new way of
doing business by dealing with functions that are not time
critical and that can be slowly introduced to the campus community,
perhaps selectively by department.
This will allow us to learn, make adjustments and better prepare for
making the big switch involved in implementing the major portions of
(We are already intimidated by the thought of introducing new
procedures required by the systems and training half the campus.)
It will also take much of the pressure off the departments, allowing
them to slowly adjust and become familiar with the use of our mainframe
- The BASIS applications being addressed are very large and very
complex, as indicated by the documentation produced to date and the
lengthy and detailed
discussion that takes place over seemingly simple issues.
Dividing the applications up and addressing them in pieces is one way
of making them more manageable.
- A phased approach will provide the project teams with experience in
implementing a system in the UAF environment using Natural, ADABAS, NSM
version 2 and TARGET.
This is something that none of us has done before, and therefore will
surely be full of surprises and learning experiences.
This will not only better prepare us for the remaining phases of the
projects but will also provide some knowledge base for estimating the
effort that will be required,
something that is impractical to do at this time.
- The initial phases should be small, manageable and require few
interfaces with systems that will be replaced.
This will provide the entire project team
with experience involving the complete life cycle
of a project: from analysis through development, testing, training
This also allows us to begin receiving some return on our
investment sooner than would otherwise be possible.
- Successful implementations will build confidence within the project
team, the user community and management.
This confidence is necessary, but difficult to maintain while working
on very large, complex, multi-year systems.
- Progress on the projects will be demonstrable.
It will be more tangible than meeting summaries, specification
documents, and data dictionary reports.
The "walls of the building" will be going up, thus assuring
management that real progress is occuring and that the project team (or
their leader) doesn't need to be intimidated into accepting
unreasonable schedules, fired or run off.
Recommendations for initial phases to be developed and implemented
for BASIS I and BASIS II are contained within those project sections of
Progress on the core architecture to be used for the development of
the BASIS applications has continued, headed up by the hidden member of
our team Kathryn Cantrell (we never let her go to meetings).
Specific accomplishments for September included:
- A macro was developed to generate programs to perform an
application HELP function.
- New topics for on-line help were developed and our standard help
routines were modified to make these topics available.
(These topics were related to the new features available with NSM v2.)
- The functional specifications for version 2 of the NSM architecture
have now been completed.
- The functional specifications for UAF Program Generator are in
final revision and will be published for Computing Services personnel
- The test version of the NSM Maintenance System has been completely
converted to the NSM v2 architecture.
- New procedures and programs have been developed to load
documentation segments to Predict (our data dictionary) where they will
be used for on-line help.
The previous procedures required the use of Waterloo Script which was
not 100% compatible with IBM Script/DCF, the product we currently use
- Template data areas and maps (Natural objects which define the data
and screens used by a program) were developed for use with the program
A template serves as a shell onto which the programmer adds unique data
items to meet specific processing needs.
A document was also prepared during the month summarizing features
and benefits of the Xerox desktop laser printer capable of printing
MICR encoded, signed checks.
This document is in final revision and will be available shortly.
A demonstration of the printer is expected in October.
The internal classes conducted for the BASIS analysts covering NSM
v2 programs were continued into September.
These classes reviewed the models for list and table maintenance
functions, completing the walk-through of all NSM v2 models currently
The following items can be generally considered as "to dos" for
Kathryn and myself.
- Complete the updates to the NSM Maintenance System functional
- Develop a basic TARGET function module model program and update the
TARGET functional specifications.
- Develop a function module model for maintaining data that is
Note: The BASIS I system requires programs that will follow this model.
Data there is retained for historical and future
purposes by dating when it was or will be
Therefore data is never changed directly on a record, instead an
expiration date is set on the old record and a new record is created to
take effect the following day.
I must first point out that I have made little progress in
comprehending the entirety of the BASIS I systems and, therefore, this
report may be somewhat deficient.
I must also report that I have not yet found the time to
completely review the detailed and lengthy functional specifications
which Katrina and Joy have prepared.
I do recognize the thousands of hours of effort and ennumerable
meetings, discussions and considerations that went into preparing this
The fact is, our Personal Services Budget, Payroll and Personnel
applications are, as pointed out previously, very large and complex
I only hope that my efforts to understand these systems does not
detract from the main development effort.
The following are possible modules of BASIS I that will be
considered for phased implementation:
- Billet management
- Billet management and budget cycle within the
Personal Services Budgeting system
- Wage rate approvals and hourly time accounting
- Vacation and sick leave accounting
The concept of a phased implementation has not yet been discussed
with Human Resources, so there may be other possible modules that
should be considered.
The next step is to decide which module should be pursued and then
perform a detailed analysis of the implications of implementing that
Revision 1 of the Personnel system specifications was released
September 3rd and served as the basis for many of the discussions held
during the month.
Many internal meetings were held between Katrina, Joy and myself,
mostly in attempts to bring me up to date on the functions of all
systems, their design, and associated issues.
Meetings held external to Computing Services included:
This was a discussion with the Human Resources staff regarding
terminations, home department, check distribution, and W4 processing.
This meeting was held with Institutional Research to review their
needs for FTE data.
They also confirmed their continuing need for the existing reports they
are provided and some discussion was held regarding coordination of SSN
Two meetings were held this day.
The morning meeting was a discussion of budgeting issues with personnel
from the Budget Office and Human Resources.
Topics addressed included budgeting soft dollars, budgeting in research
Company/Cost Centers, budgeting federal funds, and budgeting at the
Agri project level.
Summer school budgeting and the concept of paying 9-month employees
based upon the days appointed in August and May were also discussed.
The afternoon meeting was held with Rhonda Houser.
Topics addressed included "allocated department" for a
billet, provisional positions, Agri's position management,
across locations, reassignment of some data elements to
different files, and use of positions for summer instructors.
This was a discussion of personnel data requirements associated
with tenure, faculty rank, disabilities, and veteran status.
Summer budgeting was also discussed.
Academic Affairs, Human Relations, and Human Resources personnel were
A great deal of progress was made on the issues addressed in the
However, in many cases more analysis and discussion is still required.
These areas are specifically identified in the issues and plans
sections that follow.
Some of the issues raised on the BASISONE list are also identified
This discussion list was fairly active during the month and continues
to serve as a good forum for exchanging information.
Computing Services has completed an analysis of the data associated
with titles, occupation codes, maximum salaries, maximum number of
positions and job categories, and the relationship of this data to
Data definitions for these files and tables is being prepared for
presentation and review to Human Resources.
(This data was previously stored on the TOT table or Title Occupation
It is difficult at this point for me to identify issues that are
truly major versus those for which we just need to work out
These are my best guesses as to the most significant issues, some of
which just represent big to dos that may take several months
to completely address.
- We need to hire and train a new person to assist in this project.
- I need more time to work on this project than I have available.
- I suspect that there may be several cases where data items have
been identified as needed, but for which there is no custodian.
I use the term custodian to reference
the person or area that will accept responsibility
for maintaining the data and establishing the necessary procedures for
collecting the data.
It does us no good to define information, develop reports and other
uses of that data, and then to find that it is not current and is not
being accurately maintained.
The "academic function" discussions recently held might be one
example and "supervisor's SSN" may be another.
The custodian and procedures to be used to collect data need to be
identified when the data is being defined.
- The requirements for defining, storing and applying the
Company/Cost Center distributions for use in charging out salary
expenses appear to be more complex than originally anticipated.
Therefore, we need more input in this area and may need to rethink and
redesign this component of the system.
- The means of determining whether moneys are available for a salary
change, billet appointment, or other activity is an area where BASIS I
and BASIS II apparently need to come together.
Tying this check to an Available Funds File and
implementing a means of projecting future salary expenses (okay, call
it encumbering salaries) will require further analysis.
- Budgeting for summer school and summer teaching appointments has
received a great deal of discussion this month, which has been very
However, I cannot say we really understand how this will be
- Extra compensation and overloads came up in
Again, we understand more about these than we did but we are not quite
sure how the system needs to be altered to accommodate these
- Security by value is apparently desired within BASIS I, but exactly
what form it needs to take and where it needs to be applied is not
This can be a major obstacle to system implementation and system
efficiency, therefore I would like to see it addressed and well
understood up front.
(Security by value refers to security definitions that would restrict a
user from access to certain data for a given screen versus
restricting access to a screen altogether.
For example, a user could be restricted to only allow
access to employees in their same department.)
The following represent our immediate plans:
- Initiate further analysis and investigation needed to plan for the
initial development and implementation of a single module from BASIS I.
- Define, in terms of the data base structure, how OIR's
FTE values will be calculated.
Determine if there are needs for other FTE values which require
calculation using a different algorithm.
- Develop programs to maintain the title and occupation code related
tables and possibly the billet and billet master files.
- Define procedures and identify programs needed to ensure that
employees are properly terminated.
- Meet with Research Accounting to investigate requirements
associated with charging out fringe benefits.
- Investigate further the impact of budgeting soft dollars, Agri
projects, federal funds, etc.
(the most impact may be to the budget book).
- Update data and file definitions as needed for functional changes,
standardization, and system efficiency (data base reasons).
- Provide assistance and direction in the development of a NSM v2
program model that will maintain data base records that are
The concept of initially implementing one module of BASIS II has
been discussed several times over the past two months by the central
Agreement by that group has already been reached regarding what that
module should be and initial investigation of the requirements of that
module have begun, although no detail analysis is currently available.
The modules that were considered are listed below.
The first is the one recommended by the central project team to be
- A budget transfer, cost transfer, internal invoice, and journal
voucher entry sub-system.
Several of these would be TARGET transactions initiated by departments.
The current facilities for processing these transactions are MSA
Budgetary Control Adjustment Documents, a component of the current
system we have to replace anyway (as opposed to most of the batch
General Ledger which we plan to retain for some period of time).
- Vendor and vendor related file maintenance facilities.
- Travel authorization requests.
- Requisition and purchasing components up through the creation of
the purchase order (replace APS).
- Complete processing for inter-departmental orders.
- A sub-set of inter-departmental orders dealing with the processing
and approval of charges (not the entry of requests and maintenance of
- An inventory system.
The Steering Committee's approval of the direction initiated by the
central project team is needed.
Progress was certainly made during September, however, we began to
wonder about our ability to move forward when the decisions reached
during August (after a great deal of discussion and debate) were
brought into question.
At this point, no reversal of any of those decisions has been made.
If we do start changing our minds after such extensive
debate, I will certainly raise a red flag and express concern about the
direction of the project and input provided to the central project team.
Meetings held during September included:
9/2 & 4
These were meetings of the central project team where we discussed
the data requirements for the requisition header file, phased
implementation, funds checking and tolerances and the laser/MICR
This meeting of the central project team discussed the requisition
line file and requirements for supplementing requisitions (the need to
change dollar values or tolerances after a bid is received and the
common practice of changing the distribution whenever the wind changes).
The central project team discussed ideas for a phased
implementation, how fax support facilities might be used, and initiated
the review of the bid solicitation file.
The central project team reviewed the requirements of an initial
module to provide direct entry of accounting transactions (budget and
cost transfers, internal invoices, and normal journal voucher entry
facilities for Financial Affairs).
Computing Services was represented at this Financial Affairs
Advisory Group meeting where internal order processing, charges for
mainframe use, networking and hardware expenses associated with
mainframe access, the need to toggle between a mainframe session and a
PC application, and the role of the advisory group were discussed.
This meeting of the central project team revealed the common
practice of Purchasing adding or deleting items to a department's
requisition in order to prepare a "bid".
This posed several problems due to our need to associate most of the
financial controls with an item and not the entire requisition/order.
We feel satisfactory solutions to this problem were developed.
Assessment of progress to date, phased implementation, project
scheduling, and completion of the review of the requisition header file
were performed at this meeting of the central project team.
The following documentation was released for review and comment
during the month:
- The bid solicitation, solicitation line, solicited vendor, and
contract file data element definitions.
- A draft version of a justification document for the laser/MICR
Revisions to the data requirements for requisitions were made and
itemized and are currently in final review within Computing Services.
This updated documentation will be released shortly.
The length of time and extensive discussion that accompanied the
review of the bid solicitation header file is testament to the fact
that "nothing is easy".
There is no change in this list from last month's report.
I would like to say we have decided on an approach for handling
internal orders since it has been out there for discussion for several
months and seems to have survived.
The Steering Committee should probably bless this concept to provide
the necessary implementation support.
A copy of the August 27 "Internal Order" summary document will
accompany this report.
- There is a need to replace or interface with various inventory
systems. The areas that have a possible interest in such a facility
include: Scientific Supplies, Dining Services, Physical Plant and
Cooperative Extension Service.
- No decision has yet been reached regarding inter-departmental
orders, although there seems to be a great deal of acceptance of the
- A method of identifying and reporting federal expenditures by the
period of the obligation needs to be identified.
- We plan to develop a general purpose facility to provide word
processing-like capabilities for requisition and purchase order
descriptions, but need some time to do some prototype work in this area.
- The requirements of the system remain chock full of exceptions and
special handling requirements.
We hope we can document all of them and develop a system that takes
them into consideration.
The following represent our immediate plans:
- Document and distribute the data requirements for purchase orders.
- Develop an overview for requisition processing.
- Reach a firm decision regarding the processing of internal orders.
- Initiate development of programs to process vendor related data
- Define an Available Funds File, tolerances to be
employed during funds checking, and the company/cost center attributes
that will govern how funds are checked.
We hope to do this in a manner that will be somewhat flexible regarding
the methods employed for funds checking.
- Design the system components for maintaining encumbrance balances
and performing funds checking.
- Meet with more departmental "bookkeepers" regarding some of
the basic concepts we plan to incorporate into our system and solicit
their opinions and feedback.
Please feel free to raise any questions or concerns prompted by this