Appendix F

UCOP Benefits Systems Re-Engineering

University of California
Office of the President
Information Systems and Computing

April 11, 1997

  1. Introduction
    2.

    The UC Benefits organization is currently undergoing some substantial changes. The existing organization will be challenged to increase efficiency, provide increased levels of end-user satisfaction, and increase support for Campus Benefit Representatives. A Business Processing Reengineering (BPR) Project supporting the following three populations:

    will address these concerns by addressing the following BPR Objectives:

    1. To Increase Efficiency of the Benefits Operating Units - Benefits is currently challenged with the problem of getting more work done per person. Each unit's work flow should be analyzed and reengineered. Newer technologies such as Work Flow tools and Imaging can help facilitate a reengineered environment which results in increased efficiency.

      2. Some sub-objectives are:

      1. Process Reengineering - Before any automation is considered, each business unit's work should be analyzed. Existing assumptions and bottlenecks will be examined and modified, if and as appropriate, resulting in a streamlined work flow process. The work flow of each unit should then be formalized into tasks in which work will be automatically routed from station to station, taking advantage of modern tools. As a result, work will be done more quickly with less effort and enhance the service to the customer.

      2. Consolidation of Systems and Data - There are currently both mainframe systems and quite a number of PC/LAN - based systems which Benefits uses for management information and operations. Each has some different functionality, but also a great deal of redundant data as well. The information contained in these various databases should be consolidated such that a central data repository has multiple modes of access (e.g., clients such as GUI1 tools, IVR2, and Web) both for end users and university staff at UCOP and campuses. Overall data redundancy will be reduced, however some data redundancy may be retained to optimize performance of different functions, (e.g., operations vs. analysis).

      3. Reports and Microfiche - Benefits currently stores a large number of reports, both on paper and on film. Some are retained for short periods of time for current reference (usually on paper), others are stored indefinitely (usually on Fiche). Paper reports take up a lot of space; Fiche reports are cumbersome to retrieve. The need for reports should be evaluated during the reengineering process to determine if a report can be:

        1. eliminated by a business process,
        2. converted to an on-line query, or
        3. stored on optical disk where it can be retrieved easily.

      4. Modernize the storage and retrieval of Customer Files - All correspondence from and to employees is currently kept in paper form. Retrieval of these files is a time-consuming and labor-intensive process. To facilitate service to the customer this correspondence should be available electronically, i.e., through electronic imaging. Availability of these images to campus benefit offices will also be considered.

      5. Provide Additional Functionality - There is a list of over 100 requested enhancements to the existing system which have been deferred until the BPR project. This list should be reviewed and these functions incorporated into the redesign where appropriate.

    2. To Facilitate Access to UCRS/BCS data from Campuses - With the decision to distribute more responsibility for Benefits Customer Service to the Benefit Offices, it will be necessary to provide both inquiry and perhaps limited update capabilities at campus locations. The client must be easily supported at remote locations, i.e., a "thin" client, while providing considerable functionality.

    3. To make more information and control available to the customer - Enhancements to existing IVR systems and expansion of the concept to Web applications will empower the employees to retrieve and update account and enrollment information.

    4. Security - Because Benefits data is distributed across multiple platforms, there is no central security mechanism controlling access to data. Consolidation of data will also facilitate a single access control mechanism. For employee access, utilization of the existing PIN database will be used. This concept may be expanded (although not necessarily as part of this project) to authenticate persons other than UCRS members, e.g., students.

    UCOP Benefits Systems Re-Engineering is first a restructuring of many Benefits operational procedures and second the revision or replacement of the data processing application systems that support them. Its basic objectives include expedited operational processes, less data redundancy, better service to campuses and end customers, and enhanced flexibility for incorporating new functions into the system. It will require a significant amount of time and resources, over a phased implementation timetable. The remainder of this document will present a preliminary technical analysis of the issues to effect this project successfully.

  2. A Review of Existing Application Systems
    3.

    The existing application systems which are candidates for the re-engineering project are:

    1. UCRS

      2. The current UCRS application was developed in the late 1970s in a COBOL/CICS environment running under the IBM mainframe DOS/VSE operating system. In 1989-90, UCRS was converted to run completely3 under the IBM MVS operating system and at the same time was moved from a third-party administrative service bureau, Glen Slaughter and Associates (GS&A), to an internal operation within UCOP. There are three primary systems which comprise UCRS: Membership4 (MEM), Annuitant (ANN), and Insured annuitant (INS). The MEM system utilizes data input from the local payroll systems and provides data to BCS. 1099R tax forms are generated in both the ANN and MEM systems. There are numerous other external interfaces. Among the positive, general features of the current UCRS system are:

    2. BCS

      3. The current BCS application was developed in the mid 1980s. BCS generally incorporates FOCUS, COBOL, and ISPF-dialogs running under the IBM mainframe VM/CMS operating system. It currently supports a modeling function for the local benefit representatives as well as actually performing retirement calculations for the operational retirement unit to be used in the ANN system. Modeling functions include retirement estimates, 403(b) savings estimates, and net pay calculations based on selected deductions. Its primary databases are completely updated (replaced) on a monthly basis utilizing data input from the campus payroll systems as well as the UCRS MEM application.

      Incorporating the BCS functions into the reengineered UCRS or the Payroll/Personnel System, as appropriate, will lessen data duplication and sharing of data and provide more current data for retirement calculations and modeling so that a separate, non-integrated application will not be required.

      Specifically,

    3. BATS

      4. The current BATS application serves as a "tickler file" system for tracking workflow, e.g., it identifies where in the operational process a document submitted by a UCRP member resides. There are currently no such system-maintained workflow tracking functions in either UCRS or BCS.

      Incorporating tracking functionality into the re-engineered UCRS will automate existing manual, operational procedures so that this separate, non-integrated application will not be required.

    4. OTHER SYSTEMS

      5. There are a number of small database systems which have been developed and are maintained by Benefits units. These systems were written in Foxpro, Dbase, or PC-File; however, some are manual systems, maintained, for example, on index cards.

      Where applicable, these systems will also be incorporated into the common database and the functionality adapted into the new system.

  3. Preliminary Recommendations
    4.

    The following lists a series of initial assumptions:

    1. Given their currently sound functionality, batch processing will continue to be executed in the MVS mainframe environment and will continue to utilize COBOL II (or its successor, COBOL/370) as the primary batch processing language. This strategy will eliminate the need to rewrite major portions of the existing system, significantly reducing project risk and timeline.

    2. The re-engineered system's primary databases should be relational. This will facilitate access by a number of "client" platforms. Furthermore, based on its pre-eminence in the MVS production environment, DB2 is planned as the database engine. DB2's backup/recovery utilities, security, concurrency features, etc. make for an ideal selection. Release 5.1 will additionally support remote procedure calls (RPCs) and triggers which will be utilized to allocate efficiently the workload between the mainframe (acting as a server) and the client workstations, as well as an open server capability, opening the door to access by any SQL client, be it a Web server or RAD6 platform such as Powerbuilder.

    3. The re-engineered system should access the same primary databases and integrate better the following general processes:

    4. There will be two types of online access to data: local access via "thick" clients, and remote access via "thin" clients.

      5. "Thick" clients will be used in the Benefits office only, where they can be "served" from a central server. This keeps the software distribution problem under control. Most clients, e.g., Powerbuilder or Filenet Desktop, will be executed under control of the Workflow processor.

      "Thin" clients will be used for campus Benefit Offices and for Individual Employee access. Modeling screens, replacing the current BCS screens serve as one example of an application which will be rewritten as a Web-based application. It should be noted the local Benefit Representatives will only be required to have the ability to run a Web-browser utilizing TCP/IP, in order to, among other things, access UCOP-administered applications over the internet. Employees will be able to inquire into their personal accounts and update certain data elements either by IVR or by Web-enabled applications.

      The existing CICS, FOCUS, and ISPF screens will therefore be eliminated in the long-term.

      "Screen-scrapers" will not be employed, except possibly for pilot projects when time constraints may necessitate such approaches. Screen-scraping represents a sometimes convenient, but not robust technology.

    5. The payroll processes will need to be revised, ideally integrating and increasing the frequency of the existing UCRS and BCS interfaces to lessen data redundancy. It should be noted that BCS currently shares payroll interfaces with the Corporate Personnel System (CPS).

    6. The batch programs will require two basic types of revisions: first, they will need to be modified to access the relational database and second, they will need to be enhanced for maintainability.

    7. Direct database updates will be permitted via workflow-launched applications or by certain other remote (i.e., Web or IVR) client applications; however, for control reasons, the existing practice of performing financial membership transactions only via batch processing will be enforced in the new system as well. Online applications may facilitate demographic, e.g., name/address, changes, but all financial based membership checkwrite transactions will be posted to a transaction holding file (THF) for later batch processing.

    8. A new comprehensive disaster recovery plan will need to be devised which takes into account the DB2 databases, the remaining mainframe (batch) software, and client software, in coordination with the backup/recovery plans for the imaging and IVR systems.

  4. Re-Engineering Milestones

    5. Given the preceding preliminary analysis, the milestones of the re-engineering project are as follows:

    1. Parallel Projects to Support Off-Site users with IVR and Web Interfaces

      2. IVR and Web-based applications are ideally suited for users who are not physically located at UCOP. This population is

      The development and deployment of IVR applications has been underway since mid-1995. To date, applications have been written and installed which give employees access to 403(b) and payroll information, as well as support open enrollment and UCRS board elections. These applications (or updated versions of them) will be extended to Web access as well. Future IVR/Web applications may include:

      Campus Benefit Office users will not require the same specialized application software used by UCOP users. Rather, they will be able to access various functions with a Web browser. This eliminates any software distribution issues outside UCOP's offices.

      These projects will proceed on an ongoing basis in parallel to the re-engineering effort.

    2. Pilot Re-engineering Project

      3. The first step in the re-engineering process is to re-engineer one subsystem. The advantages of this approach are:

      Although the re-engineered subsystem will have its own relational database, it will still need to access some components of the existing VSAM database. This will be converted when the entire database is converted in the next step.

    3. Convert the Database

      4. A phased approach for converting the existing application databases to DB2 will be pursued. The new architecture will provide the base of support for the re-engineered applications and will include as one of its objectives, a lessening of data redundancy. The design for the new databases and tables will thus be an initial and integral component of the re-engineering project. Preliminary conversion programs and access modules will be required in order to support the existing programs (both CICS and batch) to access the new database. As the re-engineered application processes evolve, the new databases and tables will be correspondingly refined further and the CICS programs phased out.

      Release 4.0 of DB2 will additionally support Remote Procedure Calls. These are pre-programmed processes that are executed by DB2 on the mainframe at the request of clients. These will prove very useful in allowing the mainframe to handle much of the application processing load, leaving the client workstations to devote more processing power to their graphical interface capabilities.

    4. Revise the Online Interfaces

      5. Online interfaces will support a consistent functional division between update and inquiry screens. The client workstations will incorporate a variety of front-end applications, avoiding a 3270-centric approach. The client platforms will thus allow for more powerful and flexible functionality and will include:

    5. Implement Automated Workflow

      6. The re-engineered system will incorporate workflow processing for all operational update procedures, e.g., disability, insurance, loans, refunds, retirement. Processing will execute workflow scripts to improve operational procedures by, among other features, routing electronic document images, incorporating timely data retrieval from the databases, and facilitating expeditious database updates.

    6. Support Workflow with IVR and Web

      7. As the re-engineering process proceeds, the IVR and Web applications will take advantage of the new relational DB2 database, providing a tighter integration with the UCRS systems. IVR and/or Web access will, in many cases, be used to input data to be processed by the operational units. In this case, transactions will be created by the IVR or Web application for processing by the appropriate batch process.

    7. Improve Application Maintainability

      8. Expediting the turnaround time and lessening the complexity of application maintenance and enhancements will be accomplished by the increased employment of:

    8. Improve Access to Reports

      9. The first step will be to analyze the requirements for printed reports and replace them, as appropriate, with on-line queries. The remaining reports should be reviewed to determine the best way for them to be read. Some reports are necessarily printed on hard copy, as they serve as worksheets. Other reports, however, could be archived as COLD (Computer Output to Laser Disk) documents on the imaging system and reviewed via image retrieval instead of on hard copy. Not only does this facilitate permanent storage of the reports, but perusal of the reports should be easier with the assistance of FileNet software. Reports that are currently archived to fiche should also be considered for optical storage, as retrieval of information will be much quicker from optical disk than from fiche.

    9. Increase System Availability

      10. Relational DB2 database processing will facilitate greater flexibility with respect to system availability. Update processes will be developed which do not require the simultaneous closure of all inquiry functions. It should be noted, even though system availability may be increased beyond certain daytime hours, that the project will still not pursue a true 7x24 availability schedule due to mandated requirements for database backup, recovery, and systems maintenance.

    10. Expand Application Security

      11. An expanded, more flexible security database must be employed to address access control for all clients, e.g., document imaging, report processing.

    11. Provide User Maintained Tables

      12. There are many parameters, rates, limits, etc. that are currently hard coded into the existing programs which make them unnecessarily cumbersome to change. These values change throughout the year based on a calendar schedule, (e.g., tax tables, permissible hours), or periodically depending on policy changes and/or new actuarial calculations. A facility will be provided for the users to update such values directly without having to request program maintenance.

    12. Ad-Hoc Reporting

      13. Currently, IS&C provides monthly snapshots of the major UCRS databases on the VM system which Benefits uses to perform ad-hoc queries in FOCUS. With the conversion of the databases to a relational model, this download should not be required; rather, the requirement for ad-hoc queries may be satisfied by client tools such as Q+E or Brio. DB2 security will prevent any inadvertent updating or unauthorized access.

  5. Technical Work Plan
    6.

    Implementation of the re-engineering project will be comprised of the following phases, some of which will be executed concurrently (see chart at end of document):

    1. Technical Planning

      2. Concurrent with the image and IVR pilots, re-engineering project planning has been underway. This component includes

      1. Determine technical approach for implementing new technology, e.g., tools, workflow, in each operational unit. This process will include choosing appropriate GUI tools to be used for inquiry functions.

      2. Develop technical standards and conventions, e.g., how code is to be written, how queues are set-up/processed, multi-user concurrency issues, security implementation, turnover process, documentation.

        3. note: some standards will have been developed in the two pilots.

      3. Develop application standards, e.g., standards for Menu bars, buttons, other controls.

        4. note: some standards will have been developed in the two pilots.

      4. Review all existing reports for media change to RDS, COLD, or user query.

      5. Review of system maintenance

      6. Database design. During this phase, a relational model of the databases will be created. Data modeling employed will take into consideration:
        • Access Groupings (which data is accessed together)
        • Data Ownership (is it insurance, retirement, etc.)
        • Maintenance (creation of parameter/control tables)
        • Normalization
        • Efficiency of data access

        Also important is Retention Cycle, that is, how often is data retained. Some data such as the data used for Semi-Annual Statements is reset twice each year.

      1. Determine new support software requirements, e.g., DDCS, Sybase gateways and servers, DB2 5.1.

      2. Prioritize the implementation of workflow changes in each operational unit.

      3. Develop implementation schedule.

    2. Image Pilot

      3. The image pilot is complete. This project provided a document archive and retrieval application with a limited amount of document queuing for the Disability Unit.

      note: see Image Pilot requirements and systems documents for further details.

    3. IVR Pilot Systems

      4. Several IVR systems have already been developed. These systems currently support:

      note: see individual application requirements and systems documents for details.

    4. Web Integration of IVR applications

      5. It is envisaged that virtually all IVR applications will have counterparts on the Web. The Web is ideally suited for applications such as open enrollment and new hire where text entry is required.

    5. Workflow (Loan) Pilot

      6. The Loan system will be used as a proof of concept of the reengineering process. As the Loan system is relatively standalone with minimum interfaces to the other systems (i.e., Membership) it is an ideal candidate. The processes outlined in the subsequent paragraphs will be performed for the Loan unit alone. The workflow techniques to be employed will be:

    6. Image Archival and Retrieval

      7. In order for the operational units to become familiar with handling images instead of form documents in hard copy, some or all units will be provided an image archival/retrieval system prior to implementing a full workflow system. The archival/retrieval system will be a facility where input forms are scanned and queued for processing. Information from the scanned images will then be processed using the existing CICS system. The scanned documents as well as output correspondence will be archived on optical disk for ad-hoc retrieval as required.

    7. Database Conversion

      8. Based on the database design created during the Technical Planning phase, the actual database conversion will produce an interim result which will be completed in the subsequent UCRS Batch Program Integration and BCS Batch Program Integration steps, below.

      There are a number of steps involved:

      1. Create and Populate Database: Initially, the physical tables, indexes, views, etc. will be created and load utilities coded/executed to populate the tables with UCRS/BCS/BATS data.

      2. Adapt UCRS Programs: COBOL data access modules will be written to recreate the old VSAM format records as DB2 table data is read from or written to the database. The existing UCRS COBOL programs will then be translated to call the access modules in place of existing reads and writes.

      3. Interface BCS Online Programs: As the BCS VM/FOCUS database remains constant over the course of a month, an extract program will be written to recreate the BCS FOCUS database in its existing form, still under VM. The important difference will be that all data needed to build the BCS files will come from the new DB2 database and the existing payroll interface to BCS will be eliminated.

    8. Interface Revisions

      9. The principal interface inputs to UCRS and BCS are currently from various systems at the campus and laboratory locations, CSU, PERS, and insurance carriers. BCS gets additional input from UCRS. In combining the UCRS and BCS databases, all existing interfaces will also be combined, for example, the Payroll interface to UCRS will be modified to pass what was both UCRS and BCS data at the same time. Existing BCS edit logic will be folded into the UCRS interface programs. Coordination with systems such as CPS (Corporate Personnel System) will be necessary, given the sharing of interface files between CPS and BCS.

      It will also be important to increase the frequency of updates, both to and from Payroll. Currently there is a daily update of Payroll information to Benefits for IVR applications which could ultimately replace the monthly file maintenance interface (PPI740). IVR applications such as the "new hire" application will require a daily update from UCRS to Payroll.

      At this point, the revisions detailed thus far for both the UCRS and BCS systems will be tested and put into production.

    9. UCRS Batch Program Integration

      10. This step is really a continuation of the program upgrades begun during the Database Conversion phase and would most likely be performed by the same staff. The objectives to be completed in this step are:

    10. BCS Batch Program Integration

      11. This conversion project will follow much the same pattern as the UCRS Batch Conversion. Access modules will be replaced by direct DB2 access and consideration given to upgrades for maintainability.

    11. Workflow Specification

      12. Each workflow sub-project, e.g. Refunds, Retirement, etc. will begin with a detailed plan of how each unit's work will be processed. The analysis of each of these operations is a comprehensive evaluation of how the work is best accomplished, not just from a data processing point of view, but an assessment of all the historical assumptions and rules that might be changed to provide a more efficient process. For example, in the Loan area, it was determined that a great amount of effort was spent processing loan fees - first because they had to handle and reconcile physical checks and second because many of the checks bounced. It was determined in the course of the specification, that it was acceptable to deduct the loan fee from the loan proceeds, thus saving a large amount of time, effort and complexity. So rather than simply automating an existing process, the process is made more efficient, and then the revised process is automated.

    12. Workflow Integration of GUI Applications

      13. Concurrent with the UCRS Batch Program Integration and BCS Batch Program Integration steps, the post-pilot Image/Workflow project will proceed. The utilization of document imaging and automated workflow processes will become much more sophisticated at this point. Current or Pilot processes that depended on CICS for data entry will be replaced by workflow-initiated GUI processes which will update the database directly and/or create membership batch (THF) transactions. Ultimately, these processes will replace all the CICS data entry screens, e.g., MEM 'O', 'P'. The workflow processes will also obviate BATS which can then be discontinued.

      Also in this phase, new BCS applications will be developed, including both the Web-based modeling function and "thicker" clients for use by the retirement unit to perform retirement calculations. The existing capability to provide printed reports from the modeling application will be maintained.

    13. IVR Integration

      14. Additional IVR projects will be developed concurrently with the Workflow Integration. Once the DB2 database is available, the IVR will replace its current Sybase database, which is merely a periodic download of the UCRS and PPS data, with the production DB2 database, thus eliminating the downloads.

    14. Employee Access via Web

      15. This capability will be coordinated with the Employee Systems Initiative which calls for enabling employees to update certain demographic information from Web-based applications.

    15. Report Capture, Retrieval, Distribution, Viewing and Printing Clients, including COLD (Computer Output to Laser Disk).

      16. There will be a number of facilities available for viewing and archiving reports online. Utilization of these tools should reduce the need for hard copy reports to a minimum, and hopefully eliminate the need for microfiche altogether. As determined during the system planning phase, the existing reports will be converted, if and as appropriate, to one of the following:

  6. Work Schedule and Resource Plan
    7.

    The project schedule and resource plan depends greatly on the number of resources available, schedule compression, and the impact and extent of on-going maintenance projects.

    There will also be a requirement for enhancement of workstations. The image/workflow software requires 16MB of RAM with Windows 3.1 and probably 24 or 32 with Windows 95 (which should be the development platform).

    The following GANTT chart shows the order of tasks and their dependencies. Note that many of the re-engineering project steps can occur concurrently. Resources will be estimated during the technical planning phase.

Project Sequence

UCBenS

PROJECT PLAN



PROCESS REVIEW
and
INTEGRATED SYSTEMS SUPPORT
for
BENEFITS



BENEFIT SYSTEMS COORDINATION & SUPPORT
April 11, 1997

UCBenS

PROCESS REVIEW AND INTEGRATED SYSTEMS SUPPORT FOR BENEFITS


BACKGROUND

Senior Vice President Kennedy established the Employee Systems Task Force in September 1996 to reassess the University's human resources and benefits information systems. Based on the original chartering letter, Associate Vice President Lynn, the chair of the Task Force, explained the Task Force's goals:

While the Task Force's work is not yet complete, it has reviewed a set of benefit systems enhancements and concurred that these proposals are consistent with the goals of the Task Force. In addition, the Task Force recognized that the basic tasks to be performed at UCOP in the HR and Benefits areas will not change as a result of the anticipated merger of these two units. Therefore, they concluded that work to develop systems to enhance business processes should begin.

Accordingly, UC Benefits and Information Resources and Communications have developed the attached plan to redesign core Benefits business processes, support the new processes with imaging, workflow, interactive voice response, and web -based systems, and convert and upgrade the UCRS database. The Employee Systems Task Force will continue to review the plan to ensure that it is consistent with the charge of the Task Force.

PROJECT PLAN
UCBenS

PROCESS REVIEW AND INTEGRATED SYSTEMS SUPPORT FOR BENEFITS

I. INTRODUCTION

UC Benefits administers the University of California's Retirement System (UCRS) and multiple health and welfare insurance programs which serve virtually all UC employees9. Approximately 180 UC Benefits staff members at the Office of the President provide policy, planning and operational support for the benefit programs. Their primary customers are more than one hundred benefits administrators located at the campuses and Laboratories. Their customers, in turn, are the active, inactive, and retired employees who participate in UC's benefit programs.

"UCRS" is also the term used to denote the computer system that is the primary processing and informational tool for the benefits function. This system and related databases:

In addition to the UCRS data base, a number of other large, University-wide systems contribute to the information infrastructure of the benefits function, including the Payroll/Personnel System, Benefits Counseling System and Corporate Personnel System. Also part of this infrastructure are the Benefits Action Tracking System and several PC-based data bases developed in recent years to provide additional functionality.

Over the years, the number, complexity and quality of the benefits offered by UC have greatly expanded. In 1981, the bulk of the population was in one of two fee-for-service medical plans. UC offered limited life insurance options and a disability program. Since then dental, vision, and legal plans and expanded life insurance options have been added. There is now a flexible spending account for dependent care expenses and a pretax payment option for medical plan premiums.

The retirement program now includes, among other features, a defined contribution pre-tax account and a Capital Accumulation Provision (CAP). At the same time, government regulation has grown, requiring increased management oversight, control, data retention, and reporting.

There has been a similar increase in the number of participants. In 1987 the defined benefit plan had an active and inactive membership of 86,000. Now there are 118,000, an increase of more than one-third. The number of retirees almost tripled, from 8,600 to 24,300. Over the same ten year period annual payments for retirement, disability, and death and survivor increased from $98 million to $554 million. This sum exceeds the combined operating budgets of UC Riverside and UC Santa Cruz.

After years of ad hoc modifications which push the limits of the original system architecture, the resulting UCRS is unnecessarily complex, difficult to access and modify, and contains redundant information in some cases, and insufficient information in others. Because UCRS has a very limited repertoire of functions, certain critical calculations, such as the highest average permissible compensation (HAPC), are done outside the system, e.g., by spreadsheet programs, or other stand-alone databases. Existing administrative processes for refunds, retirement and survivor claims, disability, qualified domestic relations orders, etc., are paper-based and densely layered. They rely on outmoded technologies, such as microfiche, and even non-technologies, such as index card files.

It is becoming more and more difficult for UC Benefits to respond quickly and flexibly to externally mandated changes or internally desired program enhancements. Staff have become increasingly frustrated with their inability to significantly improve work processes which now require unnecessary, duplicative, tedious, error-prone manual processes. Like all departments of the University, UC Benefits recognizes that it must operate more efficiently with its current staff, as there is little likelihood that additional staff will be authorized, even as new programs are adopted.

Since 1991 UC Benefits has planned to restructure its business processes and simultaneously upgrade UCRS. Improving one without the other would not produce the desired result. However, due to several early retirement programs in the early nineties, the project has been postponed repeatedly. At this time, UC Benefits and its partner, Information Resources and Communications, are ready to launch the major effort that will be required to revamp both business processes and information systems support.


II. UCBENS

UCBenS comprises two concurrent and integrated projects:

  1. Business Process Redesign

    2. UC Benefits will review, simplify, and streamline retirement and health and welfare operational procedures. This analysis will generate recommendations for changes in policies and procedures and in specifications for two types of computer support systems which, in turn, will be developed by IR&C:

  2. UCRS Conversion and Upgrade

    3. IR&C will redesign and convert the UCRS data to a relational database, which will provide a system that can utilize current development tools, provide customized graphical user interface (window-like) screens, make use of query tools to gain direct access to the production database, and enable easier and better maintenance for the future. This effort will include improvements to the Payroll/Personnel System interface to provide more timely data. Ultimately, the functionality currently provided by the Benefits Counseling Systems and the Benefits Action Tracking System, as well as a number of PC-based databases, will be consolidated into UCRS.

This project is named UCBenS - UC Benefits System - because its most tangible product will be an integrated computer based support system that will enable users, broadly defined to include both central and campus administrators, as well as employees, to enter, process, store, and retrieve benefits information and data.


III. PROJECT GOALS

The goal of UCBenS is to enable UC Benefits, without additional staff, to:

The resulting system will decrease processing time and increase the accuracy and timeliness of data. Consequently, it will enable staff to more effectively support campus and Laboratory benefits administrators and provide better information to management and employees for decision-making. UCBenS will make it possible for UC Benefits to meet the challenge of continuous change by increasing productivity, not by increasing staff.

After the completion of this project, and over a period of several years, the nature of work in UC Benefits would be very different from what it is today. For many routine processes, employees would initiate action electronically. For example, an employee might notify UC Benefits of an intention to retire by means of an IVR or Web application. This could trigger an automated letter to the employee containing information about tax implications, for example, and requesting certain documents, such as birth or marriage evidence. As the required documents were received, they would be scanned, imaged, and routed to a workflow application. When all necessary documentation had been logged, the workflow application would notify appropriate staff that the application was ready for processing and would generate the mailing of an election packet for the employee to complete. On its return, the packet would be scanned and imaged. The system would calculate retirement income, drawing both on data resident in UCRS and the documents provided by the applicant. When the campus processed a separation action, a daily update from the campus Payroll/Personnel System to UCRS would trigger the payment of the benefit. Staff could concentrate its efforts on doing non-routine work and quickly responding to requests for changes due to new regulations or new programs.

It is NOT a goal of the project to reduce current staff. It IS a goal that UC Benefits be more productive. It is both inevitable and desirable that the roles and responsibilities of some individuals will change as a result of UCBenS. Such changes may be difficult to navigate, but the outcome will be a department that accomplishes its work more effectively and efficiently than is now possible and responds quickly to the need for change. The result will be increased employee morale and customer satisfaction.


IV. PROJECT PARTICIPANTS - ROLES AND RESPONSIBILITIES

Project participants include the following:

The participants are organized into groups as indicated below:

Attachment 1 illustrates the roles and responsibilities of the participants. Attachment 2 identifies individual assignments.


V. CONSULTATION - CUSTOMER VOICE

A critical part of the project is the solicitation of information from customers/clients about the importance of, and satisfaction with services provided by the organization. To understand what customers, both internal and external, need and expect from a process or service, focus groups and surveys will be used. In addition, there will be periodic consultation to review the general direction and specific impacts of the project with the following:


VI. BUSINESS PROCESS REDESIGN METHODOLOGY

The business process review and redesign will proceed in four phases:

The review and design effort heavily emphasizes interactive teamwork driven by process thinking (the ability to conceptualize a process as a series of steps that lead to a desired result). Process technique often disregards organizational boundaries in order to focus on the flow of the work. Process teams will be trained in the use of other tools such as customer input solicitation, error analysis, root-cause analysis, benchmarking and best practices.

Note that phases III and IV will be reiterated. Two or three processes will be redesigned in the first iteration, and then new processes can be selected for specification and implementation.

Attachment 3 contains a detailed task breakdown and proposed schedule for Phases I and II of the business process redesign component.


VII. BUSINESS PROCESS REDESIGN TIME FRAME

The length of the first iteration of the business process redesign and IVR & Web programming is estimated at 48 - 58 weeks, not including a seven week preliminary activity which is nearly complete.

The number and length of the subsequent iterations would be determined after the first cycle had been completed. At this time the total project is expected to last up to three years.


VIII. UCRS DATA BASE CONVERSION TIME FRAME

Concurrently, IR&C will proceed with the redesign and conversion of the UCRS data base. This work is a precondition for the workflow applications that will be specified during the business process redesign.

This data base conversion work is expected to last 24 to 32 weeks. However, the programming of both the database conversion and the workflow and IVR applications specified as part of the business process redesign are contingent upon the availability of programmers. At the end of Phase II of the business process redesign, the Planning Team will determine if staffing is sufficient to allow the UCBenS project to proceed to the next phase.

Attachment 1. Roles and Responsibilities

Attachment 2. Assignments

Attachment 3. UCOP Benefits Process Redesign


FOOTNOTES:

1. Graphical User Interface

2. Interactive Voice Response

3. Prior to the conversion from GS&A to UCOP, portions of the UCRS application had already been converted to the MVS operating system.

4. MEM includes Dependent Care Plan processing and 403(b) Loan processing.

5. Application-specific coding incorporated hierarchical design structures to improve database efficiency.

6. Rapid Application Development

7. PIN: personal identification number used as another level of security

8. MS Word for Windows is required

9. For the purposes of this document, "employee" includes active, inactive, and retired employees.