Electronic Paper Flow: Dealing With The Realities Copyright CAUSE 1994. This paper was presented at the 1993 CAUSE Annual Conference held in San Diego, California, December 7-10, and is part of the conference proceedings published by CAUSE. Permission to copy or disseminate all or part of this material is granted provided that the copies are not made or distributed for commercial advantage, that the CAUSE copyright notice and the title and authors of the publication and its date appear, and that notice is given that copying is by permission of CAUSE, the association for managing and using information technology in higher education. To copy or disseminate otherwise, or to republish in any form, requires written permission from CAUSE. For further information: CAUSE, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80301; 303449-4430; e-mail info@cause.colorado.edu Electronic Paper Flow Eloy Areu, Barbara Hope, Jeffrey Lemich, Jennifer McDermott, Timothy Munn University of Maryland College Park Maryland CAUSE 93 Abstract A year ago, the University of Maryland at College Park began to automate the process for the appointment of faculty and academic staff. A major challenge that arose during system design was how to simulate electronically the flow of paper through the various stages of approval. With several hundred academic units and sub- units on the campus, and varying numbers of review and approval stages, the proposed mechanism would have to handle the most complex of situations. Realizing that there would be other campus-wide applications requiring a similar flow of documents, it was decided that the routing mechanism developed for academic appointments should be generic enough for use in applications such as purchasing, travel, and payroll. It should also provide information across various platforms. This presentation describes in detail the routing model developed, illustrating its use in the academic appointment process. It also addresses issues of implementation and maintenance. ELECTRONIC PAPER FLOW Every year the University of Maryland at College Park processes approximately four thousand faculty and associate staff level appointments. Each appointment is represented by a form that travels through a complex and exhaustive system for review and approval. As with any paper-based routing system, the academic appointment process encounters numerous delays due to various difficulties with communication, inadequate or incorrect data, unnecessary duplication and the typical problems associated with locating forms in transit. By the spring of 1992, it became evident that a paper-driven system could no longer serve all the appointment activity of a large institution. Thus, the Office of the Vice President for Academic Affairs and Provost charged Academic Data Systems with developing an on-line computer system known as the Academic Resource System (ARS) that would handle all aspects of the appointment process. A team consisting of a project manager from Academic Affairs and a technical manager and two systems analysts from Academic Data Systems began this undertaking. From the onset, the developers understood that for an electronic appointment system to be successful, it had to incorporate the complexities of the paper system. This paper system included a routing structure that, depending on the department, was either simple or extremely complex. In many cases, forms did not just travel forward; rather they traveled through an intricate network of specific reviewers and approvers. The developers concluded that a successful electronic appointment system could not function without a versatile routing mechanism that could handle the current process yet be flexible enough to deal with anticipated re-engineered processes. Better yet, if a routing mechanism had to be developed, why not make it generic so that it could be applied to similar systems across campus? The result of these efforts is the Routing and Notification System (RNS). The RNS, as applied to the Academic Resource System, has now been in use since May of 1993 and has been well received by the user community. Its generic properties make it an ideal system that can be easily applied to virtually any form-routing structure. The purpose of this paper is to discuss the development of the Routing and Notification System and describe the various applications that has made it a versatile and functional system. How paper flows To emulate, let alone improve, a form routing process, it is first necessary to examine how paper forms flow. In our case, this meant analyzing how the appointment papers route to the various levels for review and approval. The University of Maryland at College Park is a large institution comprised of over one hundred and fifteen academic departments reporting to thirteen colleges. Within this structure, some departments are very small; others are very large and contain sub-departments (centers, research laboratories, etc.) that function as separate entities. Each sub-department has its own routing process tailored to its specific needs. For example, the Physics Department has fifteen different sub-departments that process hundreds of academic appointments. Within a department or sub-department, forms may be passed back and forth between people at various levels. Each person normally has at least one back-up or proxy. Forms do not always travel upward; rather they may be passed backward to different individuals within the department for review or revision. Sometimes forms need to bypass departments or include additional stops. Depending on the application, forms may travel along simple or complex paths. In addition, people in the routing path also need to be informed that a form is ready for processing and may need to attach notes or instructions to the next person receiving the form. Attributes The RNS was developed to encompass these complexities. The attributes necessary for such a system are the following: * It must be user friendly and allow the user to perform the same routing activities that were possible with the paper system. * It must be flexible and easily adaptable to the variations existing within a large institution. * It must be generic so that it can be applied to any form-routing structure. *It must provide security by designating who has the authority to view, create, review, approve and/or reject a form. * It must prevent the forwarding of any logically incomplete forms. * It must maintain a routing history or path record of each form. * It must provide notification information that is distributed to all users along the routing path. * It must be able to inform users via electronic mail that there is a form waiting to be processed. * It must allow users to send private or permanent notes to the next person along the routing path. The Routing and Notification System possesses all of these attributes. The generic nature of the system allows it to be adapted to virtually any form-oriented structure. Generality in the RNS is achieved by using a table-based routing definition rather than a methodology that involves hard-coding. This technique allows the RNS to mimic accurately the complexity of the various academic units. One important attribute of the RNS is that it allows for customization where needed. For example, in the faculty appointment application, a rejection feature available in the RNS was customized to attach a rejection reason to the form. An application-specific table of rejection reasons is used in this instance. Similarly, the "logical completion" of a form has one meaning in the context of academic appointments, but can represent something quite different within the context of another system. Elements of RNS The RNS was developed on an IBM 9021-500 using CA-Ideal as the programming language and CA-Datacom/DB as the database engine. This was done to make the system available to any campus-wide mainframe application. The RNS provides a set of tools that are available to any application that follows the standard system architecture developed by Academic Data Systems. This base architecture includes: navigation tools to move between screens, tools to minimize re-entry of key data between screens, security to manage access to the various applications, a text editor and note storage system to handle comments, and a subsystem that provides online help. The elements used in RNS, however, could be applied to other hardware and software platforms. One of the main factors that went into the development of the RNS was incorporating levels of authority into the routing process. In a paper system, forms travel from individual to individual for different functional purposes (eg. creation, review, approval). However, in order to create an electronic routing system, this individual-based model had to be re- structured. What emerged was a new model based on the routing of forms from group to group rather than individual to individual where the group represents the functional structure. This group concept allows the RNS manager to place users in appropriate groups, and the system passes control of the form from group to group. Through a combination of user security, group definition, and user attributes, the system determines who can view, create, review, and/or approve forms. The RNS is comprised of a database and a series of online programs and subprograms that are invoked by a specific application. The specific elements of the system include: 1. An On-line Program and Database Table For Defining Units and Groups (See figure 1) An RNS administrator is required to secure each application of the system and specify the following criteria for each group: * The type of group being created. Groups may be defined as one of three basic types: Creator groups are restricted to creating new forms. They may not access any form they did not create or that was not forwarded to their group. Creators may not route forms to groups outside their department. Reviewer groups may review and reject forms within their department. They may also create forms if specified in their group definition. Reviewers may not route forms to groups outside their department. Approver groups, in addition to being able to approve or reject forms, may also pass forms to others within their department or another pre-defined office outside their department. * The route the form may take, including the primary path and alternate forwarding locations. It is possible to use pattern matching and wild card characters to tailor intricate paths. * An indicator to check if a group may be bypassed. This mechanism is used to skip specified groups along the path if they are not required to participate in the routing process. * An indicator to check if forms are logically complete before forwarding to the next group. * A processing level that may be used by the application program to protect or un-protect sensitive fields on the form as it moves through the various levels of the process. * Notification Control to specify if notification should be sent to a group. This can apply to rejections, final approval, or final implementation. 2. An On-line Program to Assign Specific Users to a Group and Define Users' Attributes (See figure 2) The RNS administrator specifies the following criteria for each user: *Users are placed into a group or groups (as defined in the previous section) depending on their functional role in the department. * Individual users can also receive electronic mail notifying them of certain routing events pertaining to their group. For example, on our campus, the majority of our users do not receive email on the administrative mainframe. For each group assigned, a flag can be set to activate an email message notifying them that there is action to be taken on the mainframe. * For each group, a restriction may be placed to prevent the group from updating or processing a form, yet still allow notification of routing actions and viewing of forms associated with the group. 3. A User/Group Selection Sub-Program Although the majority of users belong to one group, a user may be a member of multiple groups. The RNS provides such a user with an online mechanism to select a specific group within the application. 4. A Transaction Capability Sub-Program Based on the user's current group definition and the form's path records, only the group that has control of the form is able to process it. This security function is handled by the transaction capability subprogram. If path records do not exist, the processor verifies if the user belongs to a group capable of creating new forms. Any group along the routing path but not in control of the form may view it. For example, an application may allow all members of college groups to view forms created by their departments even before the forms reach the college. 5. A Processing Sub-Program (See figure 3) This subprogram is called by the application program to allow users to approve, forward, hold, or reject a form. It also maintains path and notification records. In forwarding a form, the subprogram uses information stored in the group table to display a list of possible destinations ranked in logical path order. Below is a list of capabilities provided by this module: *This module provides the ability to bypass up to nine units in the path definition. If bypassing is requested, the subprogram skips the specified groups and searches the path list for the next group that is not to be bypassed. For example, when handling faculty appointments, those for international applicants are sent to the International Education Services (IES) office before continuing to Academic Affairs. If the faculty appointment processor determines that the appointee is a U.S. citizen, then it directs the subprogram to bypass IES and forward the form to Academic Affairs. *A component of this module also provides the ability to prevent the forwarding of a logically incomplete form. When groups are defined, the RNS administrator can set a flag indicating the level of logical completion. It is then the responsibility of the application program to determine if a form is logically complete at that given point. This information is then passed in the form of a parameter to the sub-program, which compares it with the flag in the group definition table. If the form is incomplete, the sub-program will return an error code which the application program attaches to the form indicating what action must be taken. This feature allows an incomplete form to be passed back and forth between several groups within a unit, yet insures that the form is complete and correct before it leaves the unit. *This sub-program also gives users the ability to attach private and permanent notes to a form. Private notes are sent to the next group on the routing path and then destroyed when the recipient forwards the form to the next group. A user who rejects a form may attach a permanent note that can be read by anyone who has access to the form. *When an action is taken, this sub-program also returns a series of parameters to the calling application containing notification information that is to be distributed to the appropriate groups by electronic mail. It is up to the calling program to use a suitable mechanism to initiate the electronic mail transmission. On the IBM MVS platform, SMTP provides this vehicle. 6. A Path Record Sub-Program (See figure 4) This sub-program displays the path record or history for each form. The path record includes the name of each person who took action, the status (forwarded, approved, held, pending, or unread), and the date action was taken. The path record fosters accountability among users since any user with viewing capability can call up the form and see the path and status at any time. 7. An In-box Sub-Program (See figure 5) This function allows the application program to alert the user that there are forms that need an action to be taken. An entry is provided that contains the following information for each form: date/time the form reached the user, note status, description, and group name of the sender. Conclusion This paper has described the various elements that make the Routing and Notification System a success. Efficiency, accountability and accuracy are all hallmarks of the RNS. The versatility and functionality of this "paperless" system has enabled the campus to overcome a number of delaying factors that occur when routing paper forms. Because the forms are electronic, there is no wasteful duplication of paper, forms are not delayed by campus mail, nor can they be misfiled or viewed by an unauthorized user. Most importantly, since electronic forms are easily tracked, they are never "lost" in transit; thus users no longer have to play "phone tag." Using the RNS as a base routing system, the University of Maryland at College Park will have eliminated the manual routing and approval of over 4,000 academic appointment papers via the Academic Resource System. With the same base system we will shortly implement a payroll approval system that will eliminate over 50,000 pieces of paper annually. Likewise, we are also considering applications in the areas of travel approval and reimbursement and financial aid, both paper intensive processes with multilevel approvals. Despite its obvious success and acceptance by the user community, we must face the fact that a totally mainframe-based routing system is only an interim solution to the routing of forms. Increasingly administrative systems are moving, under appropriate circumstances, to smaller distributed systems. Forms processing is certainly an application that does not require the power of a large mainframe, although limited access might be required for information validation. In addition, users would prefer to access any forms application directly from their desktop rather than the more traditional mainframe logon. Thus we will be looking at porting of RNS to a more open distributed systems environment so that we can take advantage of new technology maintaining our investment in a proven activity. ACKNOWLEDGEMENTS We would like to acknowledge and thank the following people and organizations: The University of Maryland's Administrative Computing Center for their systems software and hardware support during the development of the RNS. The ARS Pilot Group for their input, exhaustive testing and rapid feedback. Kenneth C. Blythe and Dennis L. Morrison, developers of Pennsylvania State University's EASY system, who provided information during the conceptualization of the RNS. Dr. Jacob Goldhaber, former Acting Provost, who provided the incentive and resources that resulted in the development of the RNS. Maribeth Mattingly for her energy and efforts as Technical Manager of the ARS. Robert Munn, Acting Assistant V.P. for Academic Affairs, for all his vision and support, and his valuable input to this paper. APPENDIX _----------------------------------------------------------------- _RNS201P1 UMCP/RNS Routing and Notification System _JKL-LB85 Group Creation/Definition _=============================================================== == _Group ID: System: ARS Unit: 11A010 Group: ____ _ _Group Title : AGRIC ENGR Chair Status: _ (' _Appl Level : 20 (Used by the application for allowing access _Bypass Unit : N (Y/N Indicates if this Unit may be bypassed b _Capability : S (C=Create R=Review S=Submit I=Implement A=Aut _Create Forms : Y (Y/N May this group create a new form) _Complete Req : Y (Y/N Form must be complete to goto Approver o _Notify Reject: Y (Y/N Notify group if form is rejected) _Notify Approv: N (Notify on Approval - N=No, A=All, F=Fi _Notify Implmt: F (Notify on Implementation - N=No, A=All, F=Fi _Terminus : N (N=No, A=Last appr > Impl, B=Last appr stop, _Next Group : System: ARS Unit: 11A Group: 1? (Wild ca _Fwrd Group : System: ARS Unit: 11A010 Group: * (Wild ca _Link Appl : APTU (Application menu item associated with t _ Inserted: 03/29/93 Modified: ________ by _==> _____________________________________________________________ _F1=Help F2=Clear F3=Menu F6=P _F7=Prev Grp F8=Next Grp F9=Cmd Ln F10=NewGroup F12= _Make changes to the group information. _----------------------------------------------------------------- Figure 1. Screen for Defining Groups _----------------------------------------------------------------- _ARS201P1 Academic Resource System _JKL-LB85 Notification Group Management _=============================================================== == _User ID: JKL Lemich, Jeffrey Keith (ADSJKL) _Email->JLEMICH@ADS1.UMD.EDU _ -----BLOCK----- _ Unit SubGrp Translation Rcv Rej App Imp Level M _11C ____ COLL ARHU Dean N N N N 50 0 _11K020 1001 CHEM&BIOCH Creator Y Y Y Y 50 0 _________ ____ _________ ____ _________ ____ _________ ____ _________ ____ _________ ____ _________ ____ _________ ____ _________ ____ _ _==> _____________________________________________________________ _F1=Help F2=Clear F3=Menu F6 = _ F9=Cmd Ln F12= _The last group record is displayed. _----------------------------------------------------------------- Figure 2. Screen For Assigning Specific Users to Groups _----------------------------------------------------------------- _RNS905P1 UMCP/RNS Routing and Notification System _JM7-0003 Process Form _=============================================================== == _ 1994-Kanobi, Ben Obi Wan _Forwarding Choice # ____ _There is a note attached. _#### --- Possible Destinations ---------------------------------- _ 1 Approve and Submit to COLL LFSC Financial Officer _ 2 Forward to CHEM&BIOCH Chair (Alternate) _ 3 Forward to CHEM&BIOCH Reviewer _ 4 Forward to CHEM&BIOCH Creator _ 5 Forward to CHEM&BIOCH Creator (Alternate) _ 6 Forward to CHEM&BIOCH Chair Reviewer _ _ _ _ _ _F1=Help F2=Hold F3=Return F4=Read Note F5=Send Note F6 _F7=Prev F8=Next F9=Show Path F10=Top F11=Bottom F12 _Place cursor under selection and press ENTER. _----------------------------------------------------------------- Figure 3. Screen Of Possible Forwarding Destinations _----------------------------------------------------------------- _RNS907P1 UMCP/RNS Routing and Notification System _JM7-0080 Path List _=============================================================== == _ Press F8 for more c _ 1993-Adams, Abigail _ 1 HUMAN DEV Creator 1 Forwarded 05/19/93 05/2 _ McDermott, Jennifer Anne _ 2 HUMAN DEV Bus. Mgr. Forwarded 05/20/93 05/2 _ Mattingly, Maribeth _ 3 HUMAN DEVEL Chair Approved 05/20/93 05/2 _ Hope, Barbara B. _ 4 COL EDUC Reviewer 1 Forwarded 05/20/93 05/2 _ Areu, Eloy _ 5 COLL EDUC Dean Approved 05/21/93 05/2 _ Lemich, Jeffrey K. _ 6 ACAD AFFAIRS Approver Approved 05/21/93 05/2 _ Andrews, Sylvia B. _ 7 HRS Personnel Office Implement 05/24/93 05/2 _ _F1=Help F3=Return F6 _F7=Prev F8=Next F10=Top F11=Bottom _Use a function key to scroll through the data. _----------------------------------------------------------------- Figure 4. Path Record Or History For Each Form _----------------------------------------------------------------- _ARS202P2 Academic Resource System _JM7-0003 Notification of Appt. Activity _<<<< ============================================================ _Group: CHEM&BIOCH Chair _ _ Date Time Status Description Note Fro _-------- -------- ------ ----------------------------- --- ------ _10/26/93 10:03 AM New Process - (G1) Kanobi, Ben Ob Yes CHEM&B _10/26/93 08:25 AM New ARS-Rejected Appt-Skywalker, Yes COLL L _10/01/93 10:09 AM Read Process - Solo, Han CHEM&B _10/01/93 10:09 AM New Process - Darin, Robert CHEM&B _ _ _F1=Help F2=Clear F3=Menu F4=<<>>Review _F7=Scroll Up F8=Scroll Down F10=Detail _Use the cursor key to select and F5 to review a note. _----------------------------------------------------------------- Figure 5. Notification of Appointment Activity