TARGET Proposal

Table of Contents

Introduction

System Overview

Additional Considerations

Introduction

System Overview

Note: A transaction as used within the TARGET system represents a request for a specific and independent activity to be performed within an administrative system. This is normally to add, delete or update information, but may take various forms as dictated by the application implementing the activity.

The TARGET system itself only provides a framework for this processing. The administrative applications employing TARGET must be designed and written with the intent of using this framework and in accordance with specific requirements. The University is fortunate to be at the initial stage of developing new applications in the human resource, budgeting, purchasing, and financial areas which will be able to take advantage of TARGET capabilities. The TARGET components assume that applications that use these facilities will be developed using the Natural Secured Menus Architecture (NSM) and the internally developed Program Generator.

Purpose of this Document

This Proposal has been prepared to solicit support and approval for the Transaction Approval & Review Gateway via Electronic Transmission system. This document describes the features and capabilities of the proposed system. It also identifies new responsibilities and policy issues which must be addressed by the university administration for the success of such a system. This document should serve as a basis for evaluating the proposed system and, if necessary, identifying enhancements or alternate concepts that may be desired.

Background

The need and demand for electronic forms to replace paper has existed for a number of years. Many parties have moved ahead with development of screens, mimicing paper forms, where data could be entered. After entry, these screen images are printed and routed around campus as paper forms. This process may have enhanced production of the paper forms through automated word processing, but did nothing to speed the processing of data into the functional application, verify the integrity of the data entered, or eliminate the duplicate keying of information by the central office.

Some institutions have extended this approach to include the electronic routing of forms and the recording of electronic approvals. With this approach, real advantages begin to appear.

The concept employed by TARGET is a complete integration of the data capture, routing, and approval process with the administrative application for which the data is being collected. This proposal is a general presentation of this concept but addresses specific issues related to its implementation. It is the result of significant planning, research, prototyping, and discussions which began in the summer of 1991.

System Overview

Objectives

The objectives of the TARGET system can be summarized as follows:

1. Provide a core architecture to facilitate the implementation of applications which utilize a distributed data entry function combined with centralized reviews and approvals of those activities in a secure and auditable manner.

2. Employ this architecture in a generic manner such that it can be implemented in various administrative applications. This will result in:
   • The consistent use and deployment of this technology across the University community resulting in reduced training and support requirements.
   • Centralized management of control tables and all transactions.
   • Cost savings in the development process due to the shared use of the design, program code and system utilities.

3. Meet the increasing demand for electronic forms processing with a system where:
   • Data will be completely validated at the point of entry.
   • Forms will not have to be printed in order to be processed.
   • Transaction information will only have to be keyed once.
   • The original transaction will become an integrated part of the central administrative information system and the University data base.

4. Implement these facilities using the Natural programming language within the applications development framework of the NSM Architecture, both of which are proven and established at the University.

Features

TARGET offers numerous special processing features. Many of these are the result of the total integration of the original transaction entry and review processing with the base application which manages the resulting data. Some of the features, facilities, and resulting benefits provided by TARGET include:

1. TARGET will replace the use of paper forms including the need to copy, file, mail, and process these forms. Electronic transactions will replace forms, but will contain the same information for directing actions and effecting changes within the administrative systems. This will result in cost savings in the areas of copying, internal mail distribution, personnel time, and storage.

2. Electronic transactions will be available for review and approval immediately online, eliminating the time lag associated with handling paper. The benefits of more timely processing of administrative transactions are intangible and difficult to quantify, but are obviously highly desirable.

3. The basic transaction data will be entered at the point of origin and will not be re-keyed by the administrative office responsible for the application. This will reduce the data entry work load within either the central offices or within Computing Services keypunch area. Within the originating offices, the data entry function replaces the manual entry or typing of the same information onto forms. The screens used to enter data are a part of the primary application and employ strict edits and validations, which results in more accurate, higher quality information. This improvement in the integrity of the data is one of the primary benefits of TARGET. Fewer errors will result in fewer corrections and reduce the number of times and the number of people that have to handle an item. This is expected to result in significant improvements in office efficiency and productivity.

4. The ability to track and review the status of transactions will be provided. Pending, completed, and rejected transactions will be maintained in a data base and be available online for review for a period of time as defined for each transaction. Transactions may be listed by requestor and transaction status, by reviewer (pending transactions only), and by data base entity affected (this is dependent on, and varies by, transaction). This simple and rapid access to, and availability of, data is expected to reduce the number of inquiries made by departments to the central offices. This will save time both within the departments and within the office previously required to research those questions.

5. Security definitions and the review process have been designed to operate based upon a desk concept rather than an individual's ID. These position based security and transaction routing definitions provide a significant advantage over individual based security in the administration area. When security is tied to an individual and that person is reassigned within the University, all their security (access privileges) and review (transaction routing) definitions must be reviewed and updated. Position based security is just that, all security definitions are tied to a desk associated with a job so that transfers and personnel changes do not necessitate mass changes within the system. Instead, the new person is assigned to the old desk and immediately given the appropriate access and authority. Desks are associated with departments who control the assignment of those desks to the employees of the departmnet. This scheme also allows one definition to service multiple individuals since several people may be authorized to work the same desk.

6. The association of a transaction with the desks that are to be assigned the review responsibility is the heart of the electronic approval system. The TARGET system uses one central routine to make this determination for all transactions based upon the type of transaction and the data being acted upon within the transaction (referred to as the review criteria). This approach provides maximum control over the process while allowing flexibility since the maintenance and enhancement of this function is localized to one routine.

7. An optional criteria for the establishment of the desks responsible for reviewing a transaction is the dollar value associated with the transaction. Different desks may be defined based upon this dollar value. This allows assigning review responsibility for some transactions based upon the spending authority of the desk.

   Note: The dollar value is not the primary criteria which is used to determine which desk should review a transaction. Those criteria are unique and specific to each type of transaction and are described generically within TARGET as review criteria.

8. Another aspect of the establishment of the desks required to review a transaction is exception handling. If, using tables established for this purpose, the system cannot determine the desks of the reviewers based upon the transaction data, a default set of desks may optionally be defined to be established. This will ensure that a transaction is not prevented from being entered due to missing control information.

9. TARGET allows from 1 to 10 desks to be established for the review of each transaction, each assigned a review level. All approvals must be obtained at a lower level prior to the transaction being presented for review at a higher level. This will permit multiple individuals to review the same transaction at the same time while also holding a transaction back from review at higher levels until appropriate. Either or both options may be employed selectively.

   Note: The term presented is used to mean that a transaction will either appear on a transaction list for review or will automatically be retrieved for review according to its time of entry, based upon the identity of the reviewer and the desk they are working.

10. Several features have been designed into the system to ensure that the review process is simple and effective.
    • Transactions are presented in the chronological order that they were requested. Each may be approved, rejected or bypassed and the next transaction is retrieved automatically for processing.
    • To aid in the identification of what is being changed by an update transaction (a transaction where new data overlays existing information), the screen will be designed with both the old and the new values present. The old field values are displayed only when they differ from the new entries. They may also be displayed using special features such as reverse video or color, if that capability is supported by the terminal or terminal emulation software. This will allow identification of a field whose old value was blank.
    • A summary list function will be available to identify how many transactions of each type are pending an individual's review.

11. The edits and validations performed on the original transaction are invoked each time the transaction is reviewed and at the time of final posting. These consistent checks will help guarantee the integrity of the data within the University data base. Technically , these edits are performed by the same program each time, which minimizes code redundancy, the opportunity for programmer error, and the program maintenance effort when changes are required.

12. A complete audit trail is maintained for all transactions by recording the date, time, and individual performing any action on the transaction. This includes the original entry, all review actions performed, and the final disposition. This history of the transaction and review process will be available online via a pop-up window displayed by a centralized routine. Thus, complete document tracking and status checking information will be available to the originator, the reviewers, and all others with access rights to the transaction.

13. Transactions may have up to 12 comments associated with them. These short yellow stickies may be entered or viewed by anyone associated with the entry or review process. In this manner explanations and references outside the actual transaction may be communicated between the originator, the reviewers, and the central administrative office responsible for the application. A comment will be required whenever a transaction is rejected during the review process. Comments, similar to the transaction history, will be available via a pop-up window managed by a centralized routine.

14. Rejected transactions will require entry of a rejection code and a comment. In addition, a notice to the transaction originator is posted to a central data base file. These and other notices will be checked whenever a user signs on to Natural. The user is informed at that time of outstanding notices and each is displayed for their review and subsequent action.

15. The TARGET system is built on the philosophy that a desk is identified to review selected transactions as determined by the central administration. The individual or individuals associated with that desk should be the ones that normally perform that function, and it must be their responsibility to fulfill that role. TARGET will establish the appropriate transactions with that desk's ID for review expecting that review to occur. However, there will be times when all reviewers authorized to work a desk are absent and someone else must be designated to act on behalf of at least one of those reviewers. In this circumstance the TARGET system provides a proxy facility. Other individuals may be predefined, for a period of time, to act as a proxy for a desk for specific applications. The system will maintain as part of the audit trail when and who was acting as a proxy when action was taken on a transaction. The establishment of proxies will be allowed by any individual directly authorized to work a desk, but that authority must also be granted to a system administrator to be used in situations involving sickness or other unexpected absences.

16. Existing transactions, either completed or canceled, may be copied and used as the basis for entering a new transaction. The original transaction must first be selected for viewing and then the keys for the new transaction and the copy action specified. This option may be used to enter several transactions that are nearly identical or to retrieve a canceled transaction so that it can be modified and resubmitted. There may be situations where this feature cannot be provided due to the processing constraints of specific transactions.

17. All transactions cannot be maintained online indefinitly. The TARGET system provides facilities to archive, report to hardcopy or microfiche, and delete completed or cancelled transactions. Criteria for determining how long transactions are to be maintained online is based upon the transaction type and its status. In this manner varying needs of different systems can be accommodated while performing this critical function in a centralized, coordinated and timely manner.

18. Reports will be available to print all transactions of a selected type which occurred over a selected time period. This facility should assist in problem analysis and in meeting audit requirements.

19. Transaction data is stored in a generic format on the central transaction file. This means that individual fields such a salary, grade, or department are not identified as such. Instead, the applications that process the specific transactions redefine the generic data area according to their specific requirements. It can be expected that the transaction contents and generic format may change over time for a transaction. Therefore the system retains a transaction version with each transaction so that the format and processing requirements of the transaction will always be known. This will assist in the transition from new to old during periods of change.

20. The application functions used to view data will detect if there is a transaction pending for a data entity and will display the pending transaction information. It will also identify the originator and the date and time the transaction was entered. This means that the latest information will always be available, although the user must be aware that the transaction is still pending and has not received final approval.

21. The system has been designed to be as efficient as possible, attempting to minimize the data base I/O required to support the TARGET functions. For example, in normal cases only two data base calls will be required to establish the reviewers for a new transaction. This will help ensure that system response times are kept as short as possible.

22. The TARGET administrator may request a list of transactions that have been pending review longer than considered normal. The number of days a transaction may be pending before being reported may be customized via online definitions for each type transaction. With this facility, the system can be monitored to ensure that transactions are not lost within the system.

23. An e-mail interface will also be available where short messages regarding a transaction can be sent to another user. The subject of the e-mail will automatically be filled in with information identifying the transaction. This facility will be restricted to users who have a primary e-mail address identifyed within the Computing Services' directory of user IDs.

Overview

The TARGET system assumes a complete integration of the distributed data entry function and its resulting electronic approval with the application where the data is processed. In this primary area, TARGET provides a framework and model for building application programs that incorporate electronic transaction processing features. This requires the application to be designed with the intent of using TARGET and that application programs are written according to standards and models provided by TARGET. Due to this tight integration, TARGET cannot be easily overlaid onto existing applications.

In another area, TARGET provides a set of core support functions which are used independently by all TARGET applications. The establishment of the desks that will be responsible for the review of a transaction is one example of a function performed by one of these independent routines. There are many others.

A third area is the TARGET administration system. This is an application that provides operational and management support of TARGET. Functions provided by this application include maintenance of control tables and transaction routing tables; routines to archive, print, and purge transactions; identification of transactions which have not been reviewed within a reasonable period; and the ability to establish proxies for others.

Note: Since each application and its requirements are unique, TARGET is described using generic references to application components such as data base entities, data base keys (data values which uniquely identify a data entity), and transactions. Such references will be found throughout TARGET documentation.

Processes

The primary processes for TARGET can be divided into two areas, those that are performed for a transaction within an application and those which support that operation via the TARGET administration system. Each of these is discussed briefly.

The transaction processor is the key component of a TARGET application and is responsible for performing all of the following functions:

• Displaying existing application data and outstanding pending transactions when present.
• Processing the original input data for a transaction complete with data edits, the enforcement of application security, and saving the transaction for later review, posting, and audit.
• Presenting pending transactions for review and recording the results of the review (approval or rejection).
• After all approvals have been obtained, posting the transaction to the appropriate application data base.

The TARGET administration application provides facilities for managing the data required to drive TARGET systems. This includes maintenance of transaction control information, routing information (via review groups, criteria types, and review criteria), and proxies. Facilities are also provided to report transactions which have been pending too long and to archive, print, and purge transactions based upon defined parameters.

Clarifications

The following points are included to clearly state operational characteristics or issues which may have only been implied or not stated to this point.

1. TARGET provides no facility for priority coding a transaction so that its processing might be expedited. If a transaction needs to be "walked-through" the system, the originator will need to telephone the reviewer(s), identify the transaction, and request that immediate action be taken on the transaction. The reviewer can then directly select that transaction from a list and process it. It is expected that the need for this type of activity will be significantly reduced due to the speed in which the electronic entry and review can be accomplished.

2. Changes made to the review criteria will affect transactions entered after that point. Transactions entered previously are established with the reviewers and review levels that were in effect at the time of entry. No facilities have been planned or provided for altering the reviewer information (who is to review a transaction at what level) that is established for a transaction.

3. A reviewer will not be allowed to modify any information within a transaction. If a reviewer determines that a transaction has not been entered correctly or is unacceptable for any reason, the reviewer must reject the transaction. The originator may then reinitiate the transaction in a corrected form. This can be easily accomplished by retrieving the rejected transaction, copying that information to serve as the basis of a new transaction, making additional changes and corrections, and then submitting the new transaction for review.

   Note: I always wondered if this would really fly. It appears that there will be some, if not many, cases where a transaction is at least supplemented, if not directly modified, during the review process.

4. Multiple review criteria may be used to establish the reviewers for a single transaction. In this situation the review list resulting from each criteria is always merged with duplicate reviewers eliminated at their lower level. If the result of the merge process is more than 10 reviewers, reviewers at the lowest levels will be eliminated.

5. If the requestor is also established as a reviewer, based upon the review criteria, that review status is automatically set to approved.

6. Transactions which require special forms, paper work or other backup materials in the central administrative office can also be processed through TARGET. In this situation, the central office or the recipient of the paper work must be defined as a reviewer of the transaction. Special procedures must be employed by that reviewer to ensure that such transactions are not approved until the necessary documentation has physically been received. A reviewer may indicate this situation with a special status code. This hold status may be placed on transactions for other reasons and will be available on transaction lists. A comment should be added to a transaction that it is being held.

7. The system will not permit multiple transactions of the same type to be pending for the same data base entity at the same time. For example, two address changes for the same individual pending at the same time. One change would logically overlay the other at final approval and is therefore not allowed.

8. Transactions are not applied to the data base until they reach final approval. Validations associated with a transaction may involve data base checks which are affected by the completion of other transactions. Therefore it is possible that a transaction will be valid at the time of original entry but may no longer be valid when it is being reviewed. Such transactions cannot be approved. They must either be rejected or held until some subsequent action would allow them to pass validation criteria (perhaps a transfer of funds).

9. Applications that use TARGET, due to their nature of allowing distributed transaction entry, may also need to implement security by value. This will permit restrictions to be placed on what data is allowed to be entered for a transaction based upon the originator. For example, an individual in Computing Services would only be allowed to enter vacation/leave data for Computing Services and not for any other department.

10. Comments are retained as they are originally entered, there are no facilities provided to delete or alter comments. Additional comments may be entered up to the maximum allowed.

11. The transaction file will always contain the new information being submitted for the transaction. After a transaction has been completed, this will correspond to the information stored on the data base, referred to in data processing as the after image. To determine what data existed prior to a transaction being processed, the previous transaction completed for that data base entity/transaction type must be retrieved.

12. The new applications being developed are expected to employ much tighter controls and more stringent online validations than previous systems. These validations will be implemented in an integrated fashion within our total information system. This should result in fewer needs for transaction approval, eliminating many of the check points currently being employed.

Additional Considerations

New responsibilities

In order for distributed transaction entry and approval to be successful, new responsibilities must be assumed by many offices and individuals. Some of the specific areas where this is true include:

• The university administration must develop and adopt a policy endorsing the concept of electronic approval of transactions and specifically the TARGET system.
• An office and individuals must be designated to maintain the required routing tables (the review criteria and review groups) and to act as the central administrator for the TARGET system.
• Campus wide, all offices must receive the appropriate training to use the new systems that are deployed.
• The individuals designated to review pending transactions must perform that task in a timely manner.
• Computing Services must provide adequate resources for processing, storage, maintenance, support and enhancement of the system. Since these applications will become integral to almost all administrative processing, added attention may also need to be directed toward backup, recovery and disaster planning.
• Due to the wider access that will be provided to online administrative systems, security issues must be emphasized. Confidentiality of IDs and passwords will need added emphasis, auditing of computer use activities must be increased, and other policing actions instigated.
• When position based security is implemented, detail maintenance will be required of the association of desks to positions. In the interim, the association of desks to individuals requires an even greater level of activity due to personnel changes.

Security

Security issues are of greater concern when broader access is provided to applications performing critical or financial functions. Access to TARGET applications will be controlled by the same means as currently used within our financial systems, personalized IDs and private passwords. There will only be the CICS ID/password required, unlike MSA and some other systems which require dual sign ons. This will be an improvement since only one ID/password will have to be remembered (reducing the need to write them down) and the user is able to change their password whenever desired.

Access to applications and privileges within those applications are based upon definitions maintained within the NSM Maintenance System. This administrative function is performed directly by individuals within the offices with data custodian responsibility. These administrators must make the correct definitions and so must be conscientious in performing this task, however this is no different than with any other system. The same situation exists with the review criteria and review groups which must be maintained by a TARGET administrator.

Availability and Recovery

Consideration must be made for backup procedures and system recovery in case of hardware crashes or other failures which make the system unavailable. It is anticipated that such mishaps would be rare and of a short duration. This is due to the high level of reliability that exists in modern computing hardware and the use of state of the art data base technology. TARGET and the applications being considered for use with it rely on ADABAS for their data base management functions. This product is a vast improvement over VSAM, which is currently used with our MSA systems, and OASIS for the following reasons:

• Batch and online processes can execute simultaneously. Much of the downtime currently incurred by our online systems is due to overruns in the batch processing window (evening hours) or the need to immediately execute some batch process. Either situation forces the online facilities to be shut down while batch is running. This is not a requirement with ADABAS (although there may be some specific application reason that online should not be used while a certain batch process is executed). Additionally, the new applications will not rely on batch processing to the same extent as current systems. Batch will primarily be used for reporting.

• ADABAS provides superior recovery facilities in case of a disk crash. Along with the primary data base files, ADABAS maintains a protection log which contains a record of all updates performed. Regular backups are made of the data base and the protection log is synchronized to this backup. Given a disk failure, the affected ADABAS files are restored and all updates to those files are reapplied from the protection log. This process should normally require from 1 to 2 hours. OASIS offers a similar facility, but the entire data base must be recovered which requires many hours. There is no such recovery facility for our VSAM data.

The most feared form of failure is a complete disaster, where the computing center is rendered inoperable due to fire, flooding or tornado. Computing Services is actively developing a Disaster Recovery Plan which will address the complex issues that surround this scenario. In fact, some funding and a great deal of work has already been performed in this area including the selection of alternate and backup sites where processing could be performed.

The bottom line is that there will be periods when the system will not be available and manual procedures will have to be employed. Paper documents may have to be used to serve as a queue of input for the online systems, once they are available. However, except in the case of major failures or a dreaded disaster, a little patience is all that should be required to survive those periods when "the system is down".

Auditability

The audit function should be much improved with TARGET since all distributed transactions will be centrally located with a complete historical log of the review process. All transactions, complete with logs and comments, will be available online for some predefined period of time. Custom batch programs may also be developed to report transaction activity. In addition, detail reports of all transactions will be produced prior to their archival and migration from the online environment. More information should be available in a more convenient form than ever before.