Administrative Information Systems

2-0501, Academic Affairs 

July 1986

 

PRINT-FRIENDLY PDF

 

Policy 

1.01

Administrative information systems utilizing current computing technology are vital to all University administrative operations, to the reliability and integrity of University records, and to the availability of comprehensive management information for planning and decision making. It is therefore the intent of the University that resources will be invested in the use of information technology for the acquisition, processing, storage, and distribution of administrative information in situations judged to be cost effective in accordance with the planning and approval processess described herein.

1.02

All administrative systems activities (acquistion of hardware/software, implementation, operation, etc.) at the institutional level must be approved by the OSU Executive Systems Council (composed of the Stillwater campus Vice Presidents, the Director of Computing and Information Systems, and the Director of Administrative Systems Development) in a structured planning process as set forth in this policy.

1.03

The OSU Executive Systems Council will review the justification costs/ benefits and establish priorities for proposed systems activities at the institutional level. An Approved Annual Systems Plan shall be established for all institutional systems activities and the status reviewed quarterly by the OSU Executive Systems Council.

1.04

Normal systems maintenance (minor revisions) and hardware/software acquisitions of limited value may be approved by the Director of Administrative Systems Development and the Director of Computing and Information Systems without submission to the OSU Executive Systems Council.

 

Definitions, Terminology, Structure 

2.01

An administrative system is a collection of computer programs, documenta-tion, and procedures designed to carry out logical and mathematical information processing procedures, information storage, information retrieval, and display operations for one or more specified administrative operations. A system, comprised of one or many programs, in fact, becomes an integral part of normal administrative operations; it carries out established policy in a consistent and uniform manner; it provides communication between operations within a function and between different functions; creates temporary and permanent records; provides a history of transactions; and provides documents for notification, verification of status, or the transfer of resources. The recorded information and transaction history provides information for the operation of other systems and constitutes a valuable asset as a part of our “information base” supporting all decisionmaking  and planning prococesses.

2.02 

Institutional systems are generally broad in scope, support several functions, and often impact operations Universitywide. Certain systems that may impact only one department or operational area, but require a highdegree of interaction (interfacing or data exchange) with institutional systems can be implemented and operated most effectively in a shared data base environment. Such systems shall also be designated as institutional systems and derived, maintained, and operated as sub systems or by products of the primary institutional systems in order to avoid duplication of development effort, utility software, processing, redundancyin data storage, and inconsistencies in information.

2.03

Institutional systems are vital to normal on-going University operations, hence require a highly reliable operational environment. Institutional systems must be implemented, maintained, and operated in accordance with established standards.

2.04 

The integrity and continuity of institutional systems depend on key design factors that determine maintainability, transferability, and auditability.

2.05

Maintainability, the ease with which changes can be made in the system to implement new policy, is a key consideration in the design of institutional systems. This involves such factors as modularity, data independence, record structure, menu-driven tables, and record keys.

2.06

Continuity of operations of an institutional system depends heavily on transferability, the ease with which the management of the system can be trans-ferred from one technician to another. Transferability is a function of stan-dardization of documentation, design concepts, languages, job control, etc.

2.07

Appropriate up-to-date logic and information flow diagrams, program listings, and test procedures must be maintained for all institutional systems in accordance with the requirements of all internal and external audit procedures.

2.08 

Institutional data bases are collections of records that are generated and maintained by the normal operation of institutional systems. Often, different segments of the data base are controlled and maintained by different systems. Any data element in the data base may be accessed and used by any system. Data base technology encompasses the philosophy that each data element should be maintained uniquely and that any program in any system can address any data element. Institutional data bases are the primary sources of “official University records,” therefore, strict access control is required in order to avoid accidental or intentional manipulation of records, loss of information, interruption of University operations, and to protect the confidentiality and privacy of information.

2.09

Departmental systems are more narrow in scope than institutional systems normally supporting the unique operational, decision making, or planning activities/needs of one department or area. Any system, whether it consists of a single programmed procedure or an extensive collection of related computer programs, and whether it involves the use of a microcomputer, a mini, a super-mini, or a mainframe host, or any combination thereof may be classified as a departmental system.

2.10 

A departmental system is considered an independent system and shall not be directly interfaced with any institutional system nor have direct access to any  institutional data base; however, down-loading of selected data elements from institutional data bases (batch-interfacing via intermediate storage) may be provided in accordance with established security procedures.

2.11

A departmental system should not be integrated with other systems maintained and operated by areas outside of the responsibilities of the manager of the departmental system except in unusual cases. In such instances, in order to be successful, there must be a detailed agreement on and commitment to maintenance standards and practices, and documentation. Notification of changes in data, logic, schedules, etc. with adequate lead time is also required. In general, departmental systems should not be integrated across vice presidential lines of authority. There must be a single point for final resolution of systems issues.

2.12

Guidelines for classifying a system as “departmental” include considerations for the required level of complexity of the system; the importance of precision and accuracy; the importance of consistency of information with other sources; the level of resources required for implementation, on-going maintenance, and operation of the system; the level of risk to be assumed for the interruption of normal operations; and for efficiency.

2.13 

Ordinarily, an institutional system serving the common on-going needs of two or more departments/areas is more efficient to implement, maintain, and operate than multiple departmental systems.

2.14 

In many situations the unique needs of a particular departmental area can be satisfied more efficiently, timely, and with less “risk” with an extension or a sub-process of an institutional system. Institutional systems are imple-mented, documented, maintained, operated, and controlled in accordance with established standards approved by internal and external auditors. Without specialized staff with experience in these areas, it is difficult for depart- ments to maintain such standards. The requirements for institutional systems impose a higher level of structure, order, control, and specialization than can normally be achieved in user areas. It is recognized; however, that in certain situations, stand-alone departmental systems may be unrelated to the broader institutional needs in terms of purpose, function, or logic; and may in fact not involve redundancy of data entry, storage, or processing. In such cases, the flexibility and convenience of a departmental system may be desirable and justifiable.

2.15

In general a departmental system should not be implemented to carry out a major operational function where the operational responsibilities and resources of other areas might be impacted; nor where a system failure might interrupt normal institutional operations. Such a system imposes a requirement for the highest level of expertise and professionalism available within the institution. Caution should be exercised in the independent use of departmental systems that depend heavily on data to be down-loaded from institutional databases on a continuing operational basis. In general, this creates redundancy and possible inefficiency. Further, different up-dating cycles, timing of reports, and different processing logic may lead to the distribution of conflicting information both internally and externally.

2.16 

Data derived from institutional data bases are essential to certain analytical planning and decision models; however, changes in institutional systems may change the definitions or structure of data elements or the processing logic of the system and may seriously reduce the effectiveness of the unrestricted independent system or render it inoperative. Changes are made routinely on short notice in institutional systems as a result of changes in legislation, institutional policy, or to improve administrative operations. Such changes may or may not be transparent to the departmental system, depending on the nature of the change and the degree and type of dependency of the departmental system. The manager of a departmental system that depends on data from institutional data bases should maintain close liaison with the data base management, data administration and data control functions of Administrative Systems Development.

 

Procedures

Classification Authority 

3.01 

Any system may be designated an institutional system by the OSU Executive Systems Council and any system so classified shall be implemented, operated, maintained, and controlled in accordance with the policy described herein.

3.02

Normally, and except in unusual circumstances, any system or programmed procedure intended to serve information needs that are clearly departmental in scope; that is not a normal extension or sub-system of an institutional system; that does not affect operational responsibilities nor resources outside of a departmental area, and does not generate external reporting where consistency with institutional reporting is important; or any system with characteristics such that it does not warrant the institutional system classification as described in Section 2.01 shall be designated as a departmental system unless otherwise directed by the OSU Executive Systems Council.

3.03

Any proposed applications of information technology including the use of micro, mini, or main frame computers, or any implementations of office automation not classified as an institutional system by the OSU Executive Systems Council may be classified or designated a departmental system by the responsible vice president, subject to approval by the Council.

3.04

All plans for proposed departmental systems shall be presented to the OSU Executive Systems Council by the appropriate vice president for review and approval at a regular quarterly systems review meeting prior to any commitment of resources. Such plans shall include a statement of all proposed hardware/ software acquisitions, proposed application developments, and estimated total project costs including start-up and on-going production costs. The plans shall also include a statement of objectives of the project and the expected return or benefits to be derived from the proposed system. At subsequent quarterly systems review meetings the vice president should report the status of the project in terms of objectives achieved, actual costs, and benefits derived.

3.05 

Administrative Systems Development will review proposed systems, provide consultation, and make recommendations in the classification process as requested.

 

Standards and Operational Responsibilities 

3.06

All institutional systems are essential to the normal operations of the University. Therefore, in order to maintain a reliable, compatible, and cost/effective systems environment, the implementation, maintenance, and operation of all institutional systems shall conform to the standards set forth in the Administrative Systems Development Policy, Organization, and Procedures Manual.

3.07

The Administrative Systems Development manual on Policy, Organization, and Procedure defines all standards pertaining to institutional systems and is audited on a regular basis by both internal (Director of Internal Audits) and external audit authorities.

3.08

Administrative Systems Development shall be responsible for providing the philosophy, direction, and standards, and for the implementation, maintenance, and operation of all institutional systems at Oklahoma State University. This responsibility shall include but is not limited to: data structure design, determination of mode of processing, recommendations on “make-or-buy” decisions and recommendations on the selection of hardware/software.

3.09

Administrative Systems Development shall be responsible for the development and control of all institutional systems interfaces and all direct access to all institutional data bases.

3.10 

Administrative Systems Development shall be responsible for the development and control of the procedures to provide retrieval of data from institutional data bases for reporting, display, or information transfer.

3.11

The planning, implementation, maintenance, operation, and control of all departmental systems (independent) shall be the responsibility of the user-department. By mutual agreement between Administrative Systems Development and the user-department, any part or all responsibility for a departmental system may be transferred to Administrative Systems Development on a contract (direct charge) basis.

3.12

The OSU Executive Systems Council may assign the responsibility for planning, implementation, operation, and control of any departmental system to Administrative Systems Development. In such cases Administrative Systems Development shall recover all systems costs from the department served through direct billing.

 

Systems Planning Process 

3.13 

Administrative Systems Development shall be responsible for the coordination and direction for all institutional systems planning.

3.14 

To be effective, systems planning must be an on-going process. It is expected that Administrative Systems Development will provide consultation and support to all administrative areas in the analysis of needs, development of proposals to improve operations, and in feasibility and justification studies. Administrative Systems Development should also provide support in the selection of remote hardware/software and in the acquisition of data from Institutional Data Bases, and should provide standardized “user-languages” to support independent (Departmental) developments.

3.15 

Administrative Systems Development shall meet on a regular basis with each administrative area to provide consultation support, and assist in the analysis of systems needs. The plans for satisfying the needs of each administrative area will be developed as a joint effort of Administrative Systems Development and the respective administrative areas. This planning process shall include personnel from the administrative areas who are responsible for the liaison and coordination of existing systems and management personnel of the areas. Administrative Systems Development will provide those personnel responsible for the management of current systems serving the areas.

3.16

Administrative Systems Development will address all identified systems needs in conjunction with current projects, trends in information technology, and our long term systems goals in the development of recommended One-Year (Fiscal) and Three Year Institutional Systems Plans.

3.17 

Administrative Systems Development will present the proposed plans to the individual members of the OSU Executive Systems Council for their review. Each member may then present recommendations to Administrative Systems Development for modifications, additions, and deletions to the One and Three Year Plans prior to formal presentation of the plans to the Council.

3.18 

The plans with recommended revisions will then be presented to the OSU Executive Systems Council as an integral part of the Administrative Systems Development Budget Hearing Session.

3.19 

The plans shall address all new Institutional Systems activities proposed by the vice presidents. The presentation shall include estimated resource requirements, including new hardware/software acquisitions, required development effort, and on-going operational costs. Further, the plans shall present appropriate justification, as determined by the functional areas to be served, for each proposed commitment of resources in terms of estimated cost displacement, cost avoidance

and intangible benefits.

3.20 

The OSU Executive Systems Council shall review the plans and any further recommendations from each Vice President and establish an Approved Annual Systems Plan and assign an Institutional Priority to each project.

3.21 

The Approved Annual Systems Plan shall be reviewed by the OSU Executive Systems Council prior to the beginning of the “planned” fiscal year and ratified or revised in accordance with actual budgeted resources.

3.22

In order to ensure that information systems resources are utilized in accordance with the institutional priorities as determined by the OSU Executive Systems Council of the University, all hardware and software acquisitions, all new systems implementations, and all major systems revisions shall be carried out in accordance with the Approved Annual Systems Plan.

3.23 

Normal systems maintenance projects (minor systems revisions and corrections) will not be included in the plan presentation. Maintenance projects may be approved as needed by the Director of Administrative Systems Development and the Director of Computing and Information Systems.

3.24

Revisions to the Approved Annual Systems Plan may be proposed at any time by Administrative Systems Development or by any vice president. Revisions to the plan require approval by the OSU Executive Systems Council prior to the commitment of resources.

3.25

The status of all projects on the Approved Annual Systems Plan will be reviewed quarterly by the OSU Executive Systems Council.

 

Funding and Budgetary Control 

3.26

All costs incurred for the development, implementation, maintenance, and operation of institutional systems, including procurement (lease/purchase) costs for all hardware/software, training, maintenance, etc. shall be the responsibility of Administrative Systems Development. All vendor relations for institutional systems shall be coordinated by Administrative Systems Development.

3.27

This responsibility shall include remote processors (generally minicomputers located in departmental areas) that operate software that is implemented and maintained by Administrative Systems Development as an integral part of and dedicated to an institutional system. In general, terminals, microcomputers, printers, and other work stations used for teleprocessing applications such as data input, on-line updating, information retrieval, down-loading, and for stand-alone

departmental processing operations are the responsibility of the user area. Any remote devices intended to interact with institutional systems must conform to the specifications as set forth by Administrative Systems Development.

3.28

Non-E & G Budget functions of the General University and the constituent Budget Agencies of Oklahoma State University shall provide partial support for funding of institutional systems in proportion to services received as a part of the annual payments to the General University for administrative services.

3.29

All costs incurred for the development, implementation, maintenance and operation of departmental systems shall be the responsibility of the user department.

3.30

All costs incurred for data processing initiated by the user (terminal displays, ad-hoc reporting, copying data sets, etc.) and all costs incurred for developing system interfaces and down-loading data (providing information from Institutional Data Bases) shall be the responsibility of the user-department.

3.31

All costs incurred for installing dedicated hardware for a department (minis, micros, terminals, printers, etc.) and all associated costs (monthly port charges, maintenance agreements, parts and labor for service calls, etc.) shall be the responsibility of the user-department.

 

Accountability - Quarterly Systems Review 

3.32 

The Director of Computing and Information Systems shall be responsible for scheduling and arranging the Quarterly Systems Review Meeting with the OSU Executive Systems Council. The primary purposes of these meetings are:

1. To review proposed system development plans;
2. To establish priorities;
3. To review project status and costs; and
4. To reconcile the system development plans with budgeted resources.

3.33

The Director of Computing and Information Systems and the Director of Administrative Systems Development shall be responsible for presenting information (proposed one-year and three-year system development plans, progress and current status reports, systems operational costs, etc.) for all institutional systems.

3.34

Quarterly systems reviews are tentatively scheduled for December, March, June and September.

1. December Quarterly Systems Review - The primary agenda will be a review of the proposed plans for the upcoming fiscal year beginning the following July. At this meeting priorities and schedules will be established for all development projects to be included in the Approved Annual Plan for the coming year. Further, there will be a review of proposed activities for the two following fiscal years. This review is a part of the Administrative Systems Development Annual Budget Hearing Session.
2. March Quarterly Systems Review - The primary agenda will be a review of the status of all projects included in the current year Approved Annual Plan and the costs of all systems production. Proposals for modification of current or future years’ plans may also be considered.
3. June Quarterly Systems Review - The primary concern will be to reconcile the Plan for the upcoming fiscal year with the budgets for that same period.
4. September Quarterly Systems Review - This will be a general review of status and costs as indicated in the March Review.