Table of Contents

  • Common



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


    Phased implementation

    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 report. Some of the reasons and justification for taking this approach follow:

    1. The BASIS systems represent a new way of conducting business on campus. 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 the systems. (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 applications.

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

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

    4. 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 and implementation. This also allows us to begin receiving some return on our investment sooner than would otherwise be possible.

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

    6. 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 this report.


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


    The following items can be generally considered as "to dos" for Kathryn and myself.

    1. Complete the updates to the NSM Maintenance System functional specifications.
    2. Develop a basic TARGET function module model program and update the TARGET functional specifications.
    3. Develop a function module model for maintaining data that is effective dated.

      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 effective. 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 documentation. The fact is, our Personal Services Budget, Payroll and Personnel applications are, as pointed out previously, very large and complex systems. I only hope that my efforts to understand these systems does not detract from the main development effort.

    Phased implementation

    The following are possible modules of BASIS I that will be considered for phased implementation:

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


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


    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, positions borrowed 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 in attendance.

    A great deal of progress was made on the issues addressed in the above meetings. 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 there. 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 billets. 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 Table.)

    Major issues

    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 some details. 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.

    1. We need to hire and train a new person to assist in this project.

    2. I need more time to work on this project than I have available.

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

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

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

    6. Budgeting for summer school and summer teaching appointments has received a great deal of discussion this month, which has been very helpful. However, I cannot say we really understand how this will be accomplished.

    7. Extra compensation and overloads came up in September. 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 exception situations.

    8. 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 clear. 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:

    1. Initiate further analysis and investigation needed to plan for the initial development and implementation of a single module from BASIS I.

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

    3. Develop programs to maintain the title and occupation code related tables and possibly the billet and billet master files.

    4. Define procedures and identify programs needed to ensure that employees are properly terminated.

    5. Meet with Research Accounting to investigate requirements associated with charging out fringe benefits.

    6. Investigate further the impact of budgeting soft dollars, Agri projects, federal funds, etc. (the most impact may be to the budget book).

    7. Update data and file definitions as needed for functional changes, standardization, and system efficiency (data base reasons).

    8. Provide assistance and direction in the development of a NSM v2 program model that will maintain data base records that are effective dated.


    Phased implementation

    The concept of initially implementing one module of BASIS II has been discussed several times over the past two months by the central project team. 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 pursued.

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


    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:

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

    Major issues

    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.

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

    2. No decision has yet been reached regarding inter-departmental orders, although there seems to be a great deal of acceptance of the last proposal.

    3. A method of identifying and reporting federal expenditures by the period of the obligation needs to be identified.

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

    5. 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:

    1. Document and distribute the data requirements for purchase orders.

    2. Develop an overview for requisition processing.

    3. Reach a firm decision regarding the processing of internal orders.

    4. Initiate development of programs to process vendor related data components.

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

    6. Design the system components for maintaining encumbrance balances and performing funds checking.

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