BASIS Steering committee
W. David Wimberly
Bill Moody, Colleen Briney, Bill Overby and William Rains
Computing Services BASIS February Status
The Leave Accounting system is now officially in production, be it with limited data and inquiry-only access. This will change by March 15 when February balances will have been loaded and update access will be granted to all departmental leave representatives. Right on the heels of Leave will be the GJIM application, which I expect to see go into a restricted use (Financial Affairs only) production mode during March. Broad departmental use of GJIM is still scheduled for late April.
Getting this far has not been easy. In addition to all the analysis, design, and program development that has gone on, there has been a great deal of training, documentation, and set-up work required. And the reality is that there is still lots of training, documentation, and set-up remaining to be done. One of the most encompassing and possibly confusing tasks has been gathering the data for the necessary TARGET approval chains for GJIM. This has required significant effort by people all across the campus.
I mention all this in support of what I feel was a wise decision to start small and build. Leave Accounting and GJIM were chosen as initial BASIS modules because they were small, non-critical, and seemingly simple systems. It does seem like it has taken an eternity to get LEAVE and GJIM ready for "prime time", but this was a new experience for our project teams. We had users that had never seen the blank page of custom development, had never been on a mainframe, or had never heard the term 'acceptance test'; programmers that had never used Natural or ADABAS; no one with experience in electronic transaction approval processing; and a training coordinator accustomed to dealing with commercial products. On top of that, we expect a significant percentage of the campus community to become instant, productive users of the systems. What if we had tried to do Payroll or Purchasing first?
The development of Leave and GJIM has proven to be a training ground for our project team, providing us with excellent learning experiences. This will be a tremendous benefit as we address future modules. However, if we are to complete Payroll and Purchasing by the year 2000 (when, by the way, MSA will cease to function), we must make some adjustments. We have to find ways to move the design, development, testing, training, and implementation along much faster. Can we dedicate central office personnel to the project? Can we get the requirements down correctly the first time, or at least the second time around? Can we put things in perspective, focus on the big picture, and realize that the current systems don't have to be perfect right out of the box? Can we get a project manager, one that is willing and able to establish priorities and force issues to closure regardless of who is offended?
The acceptance of Leave Accounting was completed with only minor problems being identified and several issues being discussed. The problems have been addressed, and the system is now in production. The first step of conversion, loading employees eligible for leave, has been completed and the system is accessible by departmental leave reps to verify data. Leave balances will be converted from the old system as soon as they are available. Once those balances have been reconciled by Human Resources the system will be opened up for update access with March data.
Other activities have included the preparation and testing of batch jobs, minor bug fixes, continued reviews of the Leave Documentation (a book approaching 150 pages), and initial assessments of COOP's leave accounting needs. COOP personnel are now active participants of the BASIS I core team. They attend our meetings via speaker phone, which is working very well, and we are planning to do some remote training via simultaneous telephone and shared screen access of the system. We have not yet determined how to best address COOP's Leave Accounting requirements and are currently examining these needs in conjunction with hourly time reporting, since these are closely linked for hourly appointed employees. There was some discussion of eliminating hourly appointed employees, but that does not seem likely.
Future activity in the Leave area will include providing the necessary support for the production system and identifying the design changes necessary to addresses COOP's needs and integrate with hourly time reporting. We remain uncertain of how our system will be impacted by the mandates of the federal Family Leave Bill.
Progress on GJIM during February seems to be minimal because it was made up of numerous minor enhancements: added validations, added warnings, modified placement of the cursor, changes to default field assignments, new TARGET routing criteria, modified screen formats, and updates to the text of messages. Some changes have been put in one day and taken out the next. This all might seem to be grounds for going to a "spec it, sign off on spec, and deliver product as speced" approach, but I don't think that would get the systems up any faster or make them any better. I do think the experience gained on GJIM will help the definition and development of the next module go more smoothly, with fewer late breaking changes.
During February we also made some refinements to the program that extracts the documents for MSA, wrote a maintenance routine for the date and time which controls the extract, updated our GJIM system overview, corrected some of our bugs, and ran into a Natural bug that we are still working to "code around". I also participated in discussions with Business Administration, Residence Life, and Continuing Education regarding concerns and issues related to the routing of GJIM documents for approval.
The development tasks remaining for GJIM include the preparation of production JCL and minor modifications to force all transactions to be reviewed within Financial Affairs so that that office can begin immediate use of the system.
A bug that allowed effective dated entries to be entered for overlapping periods was identified and has been corrected. This was the only PSB activity for this period, and no other developments are currently planned.
There was no activity during February on UPS. We still need to review with Purchasing and Accounts Payable staff the modifications made in January and the concept of processing vendor name changes as TARGET transactions.
There has not been a great deal of progress in this area, but we continue to give it much thought. Unlike what I reported last month, we are now back to needing to identify when hourly employees working in multiple locations enter an overtime situation. We thought we could get around trying to address this requirement, but apparently the Fair Labor Standards Act is clear that we should pay overtime to any hourly employee regardless of multiple jobs. We had been diverted by the special circumstance of an appointed (non-hourly) employee also working in another location on an hourly basis. In this case we should not have to pay overtime.
The detection of overtime when an employee works multiple jobs is not that difficult. What to do when it is encountered is! The problem then becomes how to divide the regular pay and the overtime pay between the cost centers associated with each job (really each wage rate). We are considering setting it up so that the first time entered is the regular pay and the latter time entered is the overtime, with a mechanism to override this default sequence.
We are also continuing to feel that we need to accept time for various and flexible pay periods, all to be paid on the same payroll. This is due to the need to accept late time sheets (after all the employee must still get paid) and the fact that some areas require more time to collect their hourly data. Doing this, however, adds one more layer of complexity to overtime detection since time for a past pay period may throw an employee into an overtime situation for a week in which the employee has already been paid.
The other area that is causing us much aggravation is hourly appointed employees, the only group that is eligible for leave and paid on an hourly basis. This presents a problem since the leave data is needed on a different schedule than the hourly time. We are considering imposing a fixed schedule for reporting hourly appointed employees' time worked and absences, all as part of one process. This will eliminate the triplicate entry currently done: hourly time sheets, leave sheets, and overtime sheets. However, the timing issue may still be a major problem for the Cooperative Extension Service since it is more difficult for them to collect the necessary data from their numerous remote locations.
In spite of some of the uncertainties, we have proceeded to define some files and build some prototype programs for hourly title code and wage rate maintenance. Financial Aid has not yet tested the protype entry screens developed last year for work study time entry.
There was no activity in this area during February. Sandra is near completion of a system data flow, a definition of the general processing requirements, and the data element definitions.
In the area of desk-based security, Kathryn and I conducted one more "desk management" training class. To date we have trained all but 1 person that had requested and been authorized for this function. We now need some way of pushing this responsibility out to other departments. To accommodate the Division of Agriculture, we increased the number of budgetary units permitted per desk administrator to 45.
An enhancement was added to all list functions so that quit/next processing would be available when suspended to one list from another.
February activity included changes to some TARGET messages, removal of the default rejection code 'I' for invalid transactions, some hands on training with Colleen and the three TARGET Administrators, and the addition of a new list function to the TARGET administration system. This list, LRGS, presents all review groups that contain the exact set of desk IDs specified, up to 10. We continue to work on a list function that will identify transactions that have been pending longer than considered normal.
Other miscellaneous "To Dos" for TARGET include long term transaction management (archiving, purging, and printing), investigation of an e-mail facility, and an update to Computing Services' documentation.
Please feel free to raise any questions or concerns prompted by this report.