The following sections contain the detailed demonstration scripts that software vendors are expected to use as the basis for structuring their presentations to the evaluation team. Individual demonstration or discussion points may be treated separately, or in combination, as long as the major points are covered in a way that allows the evaluation team to adequately score the individual items.
As mentioned in Section 2.1, some processes have an impact in other modules (i.e. a financial process that has an impact in the student services module). Processes where the evaluation team wishes to see the cross module impact have been marked as points of integration. The assumptions outlined in Section 2 apply to all of the detailed scripts, unless otherwise noted.
1.1 Cross Module Topics
1.1.1 Security
The University requires a system that provides maximum access to information while minimizing the risk of inappropriate inquiry or entry of data. It is anticipated that security will be integrated across all modules of the proposed solution, eliminating the need for multiple log-ins and passwords. Security management is anticipated at various levels, such as position number, job classification, work unit, account number and individual.
As a buyer, Secretary does not make vendor payment decisions. Her profile should be set up with a buyer group profile that has no access to payment processing capabilities. In addition, Secretary is only a buyer for specific products in one of the Schools and should only have access to information related to her school and the products she is responsible for buying.
1.1.1.1 Demonstrate the ability to access all system modules through a single sign-on.
1.1.1.2 Demonstrate the ability to restrict access based on user-defined security: i.e., the position of the user, by organization structure, by cost center/responsibility center, at the field, screen and menu level, and to restrict access based on time of year. Show how security can be set-up to provide a user with read-only access to a specific field on the screen. Show how security can limit or deny a user with view and update access to a record.
Secretary is going on vacation for a week.
1.1.1.3 Show how a user can delegate security privileges to another employee for a specified time period.
1.1.1.1 Demonstrate how the system maintains an audit trail for transactions initiated by the employee with delegated authority.
VU needs to create and maintain personal identification numbers.
1.1.1.5 Demonstrate how to create and assign unique Personal Information Numbers (PIN) to employees for use with Integrated Voice Response (IVR), Web, or terminal update facilities and show how an employee can change their PIN.
1.1.2 Workflow
VU has already developed web-based electronic forms that provide workflow for several key transactions. VU is seeking to expand this capability for the routing and approval of documents and transactions throughout all transaction processes. Current electronic forms processing provides initiation, conditional routing, tracking, review and approvals as dictated by the workflow design and we anticipate this capability will be included in any future electronic forms processing.
The Central IT Department is asked to create the workflow for a form. The form is to be initiated by the unit supervisor, forwarded to an office for informational purposes (“FYI copy”), and forwarded to either the Provost or EVP for approval based on originating department, with notification of the completion of this process back to the originator following approval.
1.1.2.1 Demonstrate how to set up the workflow to electronically route a form to appropriate personnel (unit supervisor, reviewing office, approving office, “FYI copy” office). Include the conditional routing based upon originating department.
1.1.2.2 Show how the originator can add an additional approving office when they initiate the form.
1.1.2.3 Show how a reviewer is notified that a form is available to be reviewed.
The Provost receives the form and determines there is not enough information to approve the transaction.
1.1.2.1 Show how an approver can reject a transaction and send the form back to the originator requesting additional information items.
1.1.2.5 Demonstrate how the originator can update the form with the requested information and resubmit.
1.1.2.6 Show how the originator can track the status and progress of the transaction and receives notification upon completion of the transaction.
1.1.3 Imaging
VU currently uses production-level imaging to capture paper-based information collected during the applicant selection process in Human Resources. A separate imaging system is also in place in Graduate Arts and Sciences Admissions. Both of these applications use IBM imaging products. VU is seeking to potentially improve on its existing imaging applications and expand the use of imaging into other areas of the institution that have requirements to track and store paper-based information.
VU is not interested, during the demonstration, in a vendor’s ability to imbed images into application screens through simple Windows technology. VU is seeking to understand and see which vendors have embedded / integrated imaging applications into their administrative systems in areas such as invoices, personnel, receipts, technical specifications, etc. The imaging capabilities would include, but not be limited to automatic scanning, indexing and linking to a specific application screen, panel or document.
INTEGRATION POINT:
1.1.3.1 Please demonstrate this integration and provide several client references where this integration with the specific imaging products has been completed and is in production.
1.1.1 Ad Hoc Reporting
University staff desires the ability to generate reports on an “as-needed” basis representing a query not part of the regular, “routine” reporting specifications. The University seeks solutions that allow the same query tools and reporting software to be used across all modules of the system.
Dean wants to produce a report comparing budgeted dollars and actual expenditures from all sources for all departments in the school. The report should contain the actual budget expenses from the beginning of the fiscal year for each department showing expense code items and dollar amounts sorted by expense code.
1.1.1.1 Demonstrate the ability to enter necessary selection criteria to create the report. Show how to view the report, save the report for future reference, and save the inquiry for future re run.
1.1.1.2 Demonstrate formatting options for printing the resulting report.
1.1.1.3 Demonstrate how the report can be stored electronically and retrieved at a later date.
The department decides this report is required on a regular basis and should be routed to a number of different individuals.
1.1.1.1 Demonstrate the ability to send the report to a group of individuals over email to review.
1.1.1.5 Show how to run the report in real-time or on a defined schedule (e.g. every two weeks) and be able to stop or cancel the creation of the report if it becomes a runaway report consuming the processing capabilities of the system and tying up all other processing.
1.1.1.6 Demonstrate how to define user security for each set of reports.
1.1.1.7 Create a bar chart showing total budget and actual expenditures for each department. Show the ability to drill down from summary information to the detail.
1.1.1.8 Add a ‘sticky note’ to a set of reports.
1.1.1.9 Modify the report distribution list to add a new recipient.
Dean wants the system to automatically send an e-mail notification that the reports have been sent to each department for verification based upon parameters that have been previously defined.
1.1.1.10 Demonstrate how to set up rules for automatic notification for report distribution.
VU is conducting a survey of its employees who are parents of VU students.
1.1.1.11 Show how the system can create a report showing all students and their parents or guardians who are University employees living in Greene county. Merge this report with a document for distribution to the employees via electronic mail and/or letter based upon predetermined employee preferences for receiving University correspondence.
1.1.5 Import / Export Data
The University is committed to decreasing the cost and effort of acquiring, managing, maintaining, and presenting administrative data while improving the timeliness of information it provides. A key strategy for accomplishing these objectives is to replace its enterprise-wide applications with an integrated set of applications that allow transactions to be entered once and be reflected in all appropriate modules in the system. While this strategy should reduce the need for shadow applications in departments, some of these individually maintained applications will likely be needed to supplement capabilities of the enterprise-wide applications. The University, therefore, needs the ability to interface the new central applications with these department-maintained, supplemental applications
1.1.5.1 Given the fact that VU will need to interface the new systems with existing systems and will want to use office products to enter some data, demonstrate or explain your product’s ability to provide pre-designed application programming interfaces (API’s) that allow for bi-directional data links so that existing systems can utilize the new systems information for validation and integrity. Examples would include the need to check for a valid fund or account code and the need to validate a vendor, student or employee. Possible API’s might provide the ability to call a program that performs the validation and returns a response code. This facility should accept both interactive and batch feeds of data that can be validated concurrent to the upload process.
1.1.5.2 Demonstrate the ability to produce a report that combines data from the enterprise-wide application with data from a department’s supplemental application.
1.1.5.3 Demonstrate how data from the enterprise-wide application can be downloaded to office automation products for modification and analysis. How can this information then be uploaded to system files? What security exists for this process?
1.1.5.1 Demonstrate the capability to import/export and cut/paste a journal entry to and from a spreadsheet application.
1.1.6 Web-based Transactions
Due to the growth of the Internet, including the Web, VU is interested in understanding what capabilities the software has for processing transactions over the Internet. In addition, VU is interested in using Electronic Data Interchange (EDI) and Electronic Funds Transfer (EFT) to eliminate paper-based transactions with key suppliers (banks, benefits plans), customers (parents and students) and governmental agencies. These applications could include remote data entry by university employees, customer access to VU data and functions, and supplier integration with purchasing.
Current Support Plans
1.1.6.1 Demonstrate your current capabilities and describe your plans for supporting Internet and Web applications. Please include your plans and capabilities to provide secure Web-based transactions including authentication and electronic signatures.
1.1.6.2 Show how data transfers (i.e., benefits plan enrollment changes, etc.) are currently supported via electronic commerce, including the initiation of the transaction by the employee via the web through to updating the plan provider.
Student Access
The University plans to offer students greater flexibility to receive services by providing access to frequently accessed transactions and inquiries via the web.
1.1.6.3 Demonstrate the ability for students to inquire against their account balances via the web.
1.1.6.1 Demonstrate the ability for students to update their billing addresses via the web.
INTEGRATION POINT:
1.1.6.5 To illustrate the flexibility/functionality of exporting from the Web to another sub-system, demonstrate how an employee can register for a parking permit via a Web-based application, that in turn produces deduction records for HRS, and exports data for a separate departmental parking system.
1.1.7 Help Features
The University would like to put its policies in the “help section” of the system. Additionally, it needs to provide users with online access to context sensitive help information to facilitate system use. Policies and help information should be accessible in the same manner across all modules of the system.
1.1.7.1 Demonstrate the ability to set up policy help and information. Show how personnel can easily access these policies across VU. Show how the responsible units can maintain the documentation.
1.1.7.2 Demonstrate how personnel can use the help feature to access information such as allowable values for a given field. Show the error message and help information provided when a person enters incorrect data.
1.1.7.3 Show the commonality of help information access across all the modules of the system.
1.1.8 System Tools
The University should be able to easily modify business rules, screens and other data items to meet its business needs without compromising system maintainability.
1.1.8.1 Demonstrate the ability to modify screens, menus, and data value tables, etc.
1.1.8.2 Demonstrate the ability to add new data fields to a screen.
1.1.8.3 Demonstrate the ability to change business rules that apply across VU. Show how department-specific rules that override default rules can be added. Show how department-specific rules that supplement central rules can be added.
1.1.8.1 Briefly demonstrate any other tools and technologies provided that would VU to tailor the system to its environment.
1.1.9 Software Management Philosophy
1.1.9.1 Discuss the application’s primary software management philosophy. Specifically, provide information regarding making software changes, the support for decentralized transaction processing and the variety of required levels of skills to make system changes.
1.1.10 Financial Reporting
One common characteristic of the current administrative systems at VU is that it is impossible to mark transactions and other data with local, departmental indicators. Thus, the results of the transactions can not be transformed into meaningful management reports at the department or operating unit level. In addition, regardless of the ability to mark transactions, most data entered into the current administrative systems is difficult to retrieve for any departmental purpose. The consequence of these deficiencies is that all departments and operating units have created a variety of shadow systems in order to provide information for local management purposes. VU does support a university-developed departmental accounting system, but it is recognized as a crude system that does not adequately meet the needs of the university community. It is recognized that the Information Warehouse at VU has provided the capability to extract some important management information. However, the inability of the departments to mark transactions inhibits the ability of the Information Warehouse to replace departmental shadow systems.
Similarly, at the central level, it is not possible for EVP or Provost to access sufficient enterprise-wide management information for the same reasons listed above.
The university is interested in acquiring an integrated software package that includes a modern departmental reporting system as well as an executive information system (EIS).
Departmental Management Information
1.1.10.1 One of the financial best practices is to utilize the General Ledger for summary information required to support external compliance reporting to the financial community. This best practice also means that transaction characteristics important for internal reporting and for research administration ideally would not reside in the General Ledger, but would be part of the detailed transactions located in sub-ledgers (e.g. purchasing, accounts payable, fixed assets, accounts receivable, etc.). Please explain your systems ability to attach attribute information to transactions at different locations and levels (summary versus detail) in the system. Also explain the following:
• How many separate transaction attributes are available?
• When may they be assigned to revenue and expense transactions?
• How and when may they be changed?
• How many of them are mandatory minimum requirements to operate the system and how many can be allocated to schools and departments? What is the process by which this attribute allocation takes place?
Executive Management Information
The executives at VU want ready access to enterprise-wide information, with the ability to drill down to individual transactions
1.1.10.2 Demonstrate an executive information system or data warehouse that is tailored to higher education needs and that provides a “dashboard” of enterprise-wide (defined as a summarization of all university divisions, schools, and campuses) indicators such as the following:
• Academic Productivity
• Program Profitability
• Research Profitability
• Research Achievements
• Administrative Effectiveness
• Institutional Development
• Space Utilization
Please demonstrate the ability to drill down from these general indicators into these areas of interest:
• Change in net assets
• Value of VU’s endowment
• Value of all real property (land, buildings, and equipment)
• Cash invested
• Cash not invested (idle cash)
• Sponsored programs awards by sponsor and by school and/or department
• Gift funds including raised, received and deposited and pledged funds
• Human resources information, separately and totaled, for faculty, classified, and wage employees, as follows:
• Headcount
• FTE
• Dollars expended (last year, budget for this year, year to date, and projected for this year)
• Number of enrolled students
• Tuition charged, collected, due, and past due; by school (in state/out of state), by graduate, by professional, and by undergraduate, and actual compared to budget
• Number of buildings and square feet (net and gross) owned by VU
• Accounts Receivables, Inventories, and other accruals
As mentioned in Section 2.1, some processes have an impact in other modules (i.e. a financial process that has an impact in the student services module). Processes where the evaluation team wishes to see the cross module impact have been marked as points of integration. The assumptions outlined in Section 2 apply to all of the detailed scripts, unless otherwise noted.
1.1 Cross Module Topics
1.1.1 Security
The University requires a system that provides maximum access to information while minimizing the risk of inappropriate inquiry or entry of data. It is anticipated that security will be integrated across all modules of the proposed solution, eliminating the need for multiple log-ins and passwords. Security management is anticipated at various levels, such as position number, job classification, work unit, account number and individual.
As a buyer, Secretary does not make vendor payment decisions. Her profile should be set up with a buyer group profile that has no access to payment processing capabilities. In addition, Secretary is only a buyer for specific products in one of the Schools and should only have access to information related to her school and the products she is responsible for buying.
1.1.1.1 Demonstrate the ability to access all system modules through a single sign-on.
1.1.1.2 Demonstrate the ability to restrict access based on user-defined security: i.e., the position of the user, by organization structure, by cost center/responsibility center, at the field, screen and menu level, and to restrict access based on time of year. Show how security can be set-up to provide a user with read-only access to a specific field on the screen. Show how security can limit or deny a user with view and update access to a record.
Secretary is going on vacation for a week.
1.1.1.3 Show how a user can delegate security privileges to another employee for a specified time period.
1.1.1.1 Demonstrate how the system maintains an audit trail for transactions initiated by the employee with delegated authority.
VU needs to create and maintain personal identification numbers.
1.1.1.5 Demonstrate how to create and assign unique Personal Information Numbers (PIN) to employees for use with Integrated Voice Response (IVR), Web, or terminal update facilities and show how an employee can change their PIN.
1.1.2 Workflow
VU has already developed web-based electronic forms that provide workflow for several key transactions. VU is seeking to expand this capability for the routing and approval of documents and transactions throughout all transaction processes. Current electronic forms processing provides initiation, conditional routing, tracking, review and approvals as dictated by the workflow design and we anticipate this capability will be included in any future electronic forms processing.
The Central IT Department is asked to create the workflow for a form. The form is to be initiated by the unit supervisor, forwarded to an office for informational purposes (“FYI copy”), and forwarded to either the Provost or EVP for approval based on originating department, with notification of the completion of this process back to the originator following approval.
1.1.2.1 Demonstrate how to set up the workflow to electronically route a form to appropriate personnel (unit supervisor, reviewing office, approving office, “FYI copy” office). Include the conditional routing based upon originating department.
1.1.2.2 Show how the originator can add an additional approving office when they initiate the form.
1.1.2.3 Show how a reviewer is notified that a form is available to be reviewed.
The Provost receives the form and determines there is not enough information to approve the transaction.
1.1.2.1 Show how an approver can reject a transaction and send the form back to the originator requesting additional information items.
1.1.2.5 Demonstrate how the originator can update the form with the requested information and resubmit.
1.1.2.6 Show how the originator can track the status and progress of the transaction and receives notification upon completion of the transaction.
1.1.3 Imaging
VU currently uses production-level imaging to capture paper-based information collected during the applicant selection process in Human Resources. A separate imaging system is also in place in Graduate Arts and Sciences Admissions. Both of these applications use IBM imaging products. VU is seeking to potentially improve on its existing imaging applications and expand the use of imaging into other areas of the institution that have requirements to track and store paper-based information.
VU is not interested, during the demonstration, in a vendor’s ability to imbed images into application screens through simple Windows technology. VU is seeking to understand and see which vendors have embedded / integrated imaging applications into their administrative systems in areas such as invoices, personnel, receipts, technical specifications, etc. The imaging capabilities would include, but not be limited to automatic scanning, indexing and linking to a specific application screen, panel or document.
INTEGRATION POINT:
1.1.3.1 Please demonstrate this integration and provide several client references where this integration with the specific imaging products has been completed and is in production.
1.1.1 Ad Hoc Reporting
University staff desires the ability to generate reports on an “as-needed” basis representing a query not part of the regular, “routine” reporting specifications. The University seeks solutions that allow the same query tools and reporting software to be used across all modules of the system.
Dean wants to produce a report comparing budgeted dollars and actual expenditures from all sources for all departments in the school. The report should contain the actual budget expenses from the beginning of the fiscal year for each department showing expense code items and dollar amounts sorted by expense code.
1.1.1.1 Demonstrate the ability to enter necessary selection criteria to create the report. Show how to view the report, save the report for future reference, and save the inquiry for future re run.
1.1.1.2 Demonstrate formatting options for printing the resulting report.
1.1.1.3 Demonstrate how the report can be stored electronically and retrieved at a later date.
The department decides this report is required on a regular basis and should be routed to a number of different individuals.
1.1.1.1 Demonstrate the ability to send the report to a group of individuals over email to review.
1.1.1.5 Show how to run the report in real-time or on a defined schedule (e.g. every two weeks) and be able to stop or cancel the creation of the report if it becomes a runaway report consuming the processing capabilities of the system and tying up all other processing.
1.1.1.6 Demonstrate how to define user security for each set of reports.
1.1.1.7 Create a bar chart showing total budget and actual expenditures for each department. Show the ability to drill down from summary information to the detail.
1.1.1.8 Add a ‘sticky note’ to a set of reports.
1.1.1.9 Modify the report distribution list to add a new recipient.
Dean wants the system to automatically send an e-mail notification that the reports have been sent to each department for verification based upon parameters that have been previously defined.
1.1.1.10 Demonstrate how to set up rules for automatic notification for report distribution.
VU is conducting a survey of its employees who are parents of VU students.
1.1.1.11 Show how the system can create a report showing all students and their parents or guardians who are University employees living in Greene county. Merge this report with a document for distribution to the employees via electronic mail and/or letter based upon predetermined employee preferences for receiving University correspondence.
1.1.5 Import / Export Data
The University is committed to decreasing the cost and effort of acquiring, managing, maintaining, and presenting administrative data while improving the timeliness of information it provides. A key strategy for accomplishing these objectives is to replace its enterprise-wide applications with an integrated set of applications that allow transactions to be entered once and be reflected in all appropriate modules in the system. While this strategy should reduce the need for shadow applications in departments, some of these individually maintained applications will likely be needed to supplement capabilities of the enterprise-wide applications. The University, therefore, needs the ability to interface the new central applications with these department-maintained, supplemental applications
1.1.5.1 Given the fact that VU will need to interface the new systems with existing systems and will want to use office products to enter some data, demonstrate or explain your product’s ability to provide pre-designed application programming interfaces (API’s) that allow for bi-directional data links so that existing systems can utilize the new systems information for validation and integrity. Examples would include the need to check for a valid fund or account code and the need to validate a vendor, student or employee. Possible API’s might provide the ability to call a program that performs the validation and returns a response code. This facility should accept both interactive and batch feeds of data that can be validated concurrent to the upload process.
1.1.5.2 Demonstrate the ability to produce a report that combines data from the enterprise-wide application with data from a department’s supplemental application.
1.1.5.3 Demonstrate how data from the enterprise-wide application can be downloaded to office automation products for modification and analysis. How can this information then be uploaded to system files? What security exists for this process?
1.1.5.1 Demonstrate the capability to import/export and cut/paste a journal entry to and from a spreadsheet application.
1.1.6 Web-based Transactions
Due to the growth of the Internet, including the Web, VU is interested in understanding what capabilities the software has for processing transactions over the Internet. In addition, VU is interested in using Electronic Data Interchange (EDI) and Electronic Funds Transfer (EFT) to eliminate paper-based transactions with key suppliers (banks, benefits plans), customers (parents and students) and governmental agencies. These applications could include remote data entry by university employees, customer access to VU data and functions, and supplier integration with purchasing.
Current Support Plans
1.1.6.1 Demonstrate your current capabilities and describe your plans for supporting Internet and Web applications. Please include your plans and capabilities to provide secure Web-based transactions including authentication and electronic signatures.
1.1.6.2 Show how data transfers (i.e., benefits plan enrollment changes, etc.) are currently supported via electronic commerce, including the initiation of the transaction by the employee via the web through to updating the plan provider.
Student Access
The University plans to offer students greater flexibility to receive services by providing access to frequently accessed transactions and inquiries via the web.
1.1.6.3 Demonstrate the ability for students to inquire against their account balances via the web.
1.1.6.1 Demonstrate the ability for students to update their billing addresses via the web.
INTEGRATION POINT:
1.1.6.5 To illustrate the flexibility/functionality of exporting from the Web to another sub-system, demonstrate how an employee can register for a parking permit via a Web-based application, that in turn produces deduction records for HRS, and exports data for a separate departmental parking system.
1.1.7 Help Features
The University would like to put its policies in the “help section” of the system. Additionally, it needs to provide users with online access to context sensitive help information to facilitate system use. Policies and help information should be accessible in the same manner across all modules of the system.
1.1.7.1 Demonstrate the ability to set up policy help and information. Show how personnel can easily access these policies across VU. Show how the responsible units can maintain the documentation.
1.1.7.2 Demonstrate how personnel can use the help feature to access information such as allowable values for a given field. Show the error message and help information provided when a person enters incorrect data.
1.1.7.3 Show the commonality of help information access across all the modules of the system.
1.1.8 System Tools
The University should be able to easily modify business rules, screens and other data items to meet its business needs without compromising system maintainability.
1.1.8.1 Demonstrate the ability to modify screens, menus, and data value tables, etc.
1.1.8.2 Demonstrate the ability to add new data fields to a screen.
1.1.8.3 Demonstrate the ability to change business rules that apply across VU. Show how department-specific rules that override default rules can be added. Show how department-specific rules that supplement central rules can be added.
1.1.8.1 Briefly demonstrate any other tools and technologies provided that would VU to tailor the system to its environment.
1.1.9 Software Management Philosophy
1.1.9.1 Discuss the application’s primary software management philosophy. Specifically, provide information regarding making software changes, the support for decentralized transaction processing and the variety of required levels of skills to make system changes.
1.1.10 Financial Reporting
One common characteristic of the current administrative systems at VU is that it is impossible to mark transactions and other data with local, departmental indicators. Thus, the results of the transactions can not be transformed into meaningful management reports at the department or operating unit level. In addition, regardless of the ability to mark transactions, most data entered into the current administrative systems is difficult to retrieve for any departmental purpose. The consequence of these deficiencies is that all departments and operating units have created a variety of shadow systems in order to provide information for local management purposes. VU does support a university-developed departmental accounting system, but it is recognized as a crude system that does not adequately meet the needs of the university community. It is recognized that the Information Warehouse at VU has provided the capability to extract some important management information. However, the inability of the departments to mark transactions inhibits the ability of the Information Warehouse to replace departmental shadow systems.
Similarly, at the central level, it is not possible for EVP or Provost to access sufficient enterprise-wide management information for the same reasons listed above.
The university is interested in acquiring an integrated software package that includes a modern departmental reporting system as well as an executive information system (EIS).
Departmental Management Information
1.1.10.1 One of the financial best practices is to utilize the General Ledger for summary information required to support external compliance reporting to the financial community. This best practice also means that transaction characteristics important for internal reporting and for research administration ideally would not reside in the General Ledger, but would be part of the detailed transactions located in sub-ledgers (e.g. purchasing, accounts payable, fixed assets, accounts receivable, etc.). Please explain your systems ability to attach attribute information to transactions at different locations and levels (summary versus detail) in the system. Also explain the following:
• How many separate transaction attributes are available?
• When may they be assigned to revenue and expense transactions?
• How and when may they be changed?
• How many of them are mandatory minimum requirements to operate the system and how many can be allocated to schools and departments? What is the process by which this attribute allocation takes place?
Executive Management Information
The executives at VU want ready access to enterprise-wide information, with the ability to drill down to individual transactions
1.1.10.2 Demonstrate an executive information system or data warehouse that is tailored to higher education needs and that provides a “dashboard” of enterprise-wide (defined as a summarization of all university divisions, schools, and campuses) indicators such as the following:
• Academic Productivity
• Program Profitability
• Research Profitability
• Research Achievements
• Administrative Effectiveness
• Institutional Development
• Space Utilization
Please demonstrate the ability to drill down from these general indicators into these areas of interest:
• Change in net assets
• Value of VU’s endowment
• Value of all real property (land, buildings, and equipment)
• Cash invested
• Cash not invested (idle cash)
• Sponsored programs awards by sponsor and by school and/or department
• Gift funds including raised, received and deposited and pledged funds
• Human resources information, separately and totaled, for faculty, classified, and wage employees, as follows:
• Headcount
• FTE
• Dollars expended (last year, budget for this year, year to date, and projected for this year)
• Number of enrolled students
• Tuition charged, collected, due, and past due; by school (in state/out of state), by graduate, by professional, and by undergraduate, and actual compared to budget
• Number of buildings and square feet (net and gross) owned by VU
• Accounts Receivables, Inventories, and other accruals
0 التعليقات