Present: Arlene Allen, Eric Brody, Chris Dempsey, Saturnino Doctor, Bill Doering, Doug Drury, George Gregg, Bill Koseluk, Tom Marazita, Mark McGilvray, Jennifer Mehl, Elise Meyer, George Michaels, Bruce Miller, Larry Murdock, Michael Oliva, Glenn Schiferl, Deborah Scott, Jan Smith, Chris Sneathen, Jamie Sonsini, Bob Sugar, Craig Welsh, Jim Woods
ITPG PROJECT PROPOSALS
Discussion continued on proposals.
Campus Course Management System
The campus does not currently have a campus-wide infrastructure for course management. This project suggests UCSB's participation in the SAKAI Educational Partners Program as the means for implementing a campus-wide Course Management System. In some ways this project bumps up against the Student Portal Proposal, and it was suggested that there needs to be close coordination between the two projects. Since course management would probably be a multi-portal system, the danger of a mega-portal environment and shifting technologies were seen as challenges needing to be considered. A full year of pilot testing of both the application and the necessary support structures would be required. Allowing for six months of pre-pilot development, the timeline for this project would target a CMS implementation 18 months after the FTE for this purpose have been funded and hired. The evaluation of SAKAI would be part of the pre-pilot phase. If SAKAI does not prove to be viable during this stage, then, based on clear requirements, other products would be taken into consideration; however, it is expected that SAKAI will be acceptable. Currently there are 24 instructional improvement grants that could utilize SAKAI, and indications are that many more faculty would be eager to utilize this tool.
Software Licensing Support
This proposal is much like the one submitted 2 years ago, but the current budget cuts have made the need more imperative. Assets in software need licensing, updates, tracking, etc. Some licenses contracted by the Software Depot have three-year lifespans and will expire soon. Most of the services are provided by student staffing, which has been reduced considerably due to budget cuts. Software available via the online ordering system alone saves the campus approximately $300K/yr. Phase II of this proposal adds 1.0 FTE at the AA II level to handle administrative tasks. The CNT II position would handle the legal issues in conjunction with Purchasing, licensing and recordkeeping issues, and maintain official representation on UCOP's TAS committee. It would also provide support for ongoing "tweaking." It was noted that there are some advantages to buying at the bookstore that override the savings of using the Software Depot, mainly time and availability. However, Software Depot offers substantial dollar savings and allows the purchase of manuals and media seperately. Consolidation with the bookstore was brought up, but this topic should be a separate discussion, as the bookstore is a commercial/retail operation and the Software Depot is based on volume sales. Other campuses have different systems, but require an average of 2.3 FTE to operate. The TAS group sets up a conduit reseller which we use, the structure varying from campus to campus. The Software Depot also has licensing advantages; for instance, a department can obtain licenses based on FTE rather than on a user-by-user basis. Alternate funding models were discussed: A tax/surcharge arrangement was considered, but managing such a recharge system would be difficult, and the FTE would rely on soft money, resulting in unpredictable sustainability. It was felt that the University has a responsibility to fund core (basic) services such as licensing just like any other utility. Licensing and copyright controls would be included as a part of institution's liability and responsibility. Site licenses and critical applications require TAS participation. Software Depot already exists as a necessity. The Software Depot is not part of IC's charge, and IC cannot continue the service. There was discussion about whether the Phase I and Phase II should be voted on separately, but it was felt that since both phases were important for the service they should be voted on as a single unit.
Centralized Credit Card Processing
A central credit card online processing web application does not currently exist. Berkeley has systems that they are willing to give us, and the savings in reconciliation makes it worthwhile. This proposal is for establishment of a workgroup to propose a change to business process. The need exists, as evidenced by pockets of credit card processing currently ongoing on campus. This is a business process that would require considerable organizational effort. The technology is a small part of the work required. The proposal would centralize risk and technology. Accounting has no funding or technical FTE to support this endeavor, and cannot take it on. This proposal suggested provision of funding for technology and the workgroup's study to determine implementation; business process engineering would take 90% of the work. The possibility of outsourcing through the OP website is an aspect that should be considered. It was decided that the proposal should go to the EVC as a statement of need to be relayed to the Accounting office. The administration needs to identify who should be responsible for this project and let that office determine the cost, including participation and support from departments currently involved in credit card transactions, and determine a cost/benefit analysis. It was suggested that possibly the proposal should go to Vice Chancellor Pernsteiner as a business system analysis topic. It is suggested that the Grad Division be removed from the appendix and replaced with a reference to UC Berkeley, along with a list of departments currently handling credit card transactions, and point out that it would be cheaper to do now than 5 years from now, both in funding and volume. Since there was another effort looking at accepting credit card payment for tuition which got bogged down by the question of who pays the transaction fees, this proposal should clearly articulate that it is looking for a web application with the same sort of support as currently provided by card swiping machines.
Registrar and Curriculum Data in the Data Warehouse
This project elaborates cost and extends Data Warehouse data to include student data to provide better planning, analysis, and reporting to campus. This project is evolutionary; the campus will define the required product. Santa Cruz currently uses PeopleSoft and Cognos. This would be a shadow system, providing snapshots of data rather than real-time data access. The question was raised whether the real problem was better access to real-time data, i.e., to answer whether a certain individual is currently in a course, rather than providing snapshots of data for reporting purposes. This proposal could suggest central funding with a specific cost.
Student Portal Project
This project would be to establish a team to look at responding to the student constituents. Discussion of other features that could be included besides course management included an interface with GOLD between courses, grades, and material. The need exists for a consistent process rather than many websites to produce ad hoc reports. There is also a need to have a group to set standards, allowing for a team focus and coordination of work. Coordination is an important part. A level of authority needs to be established. The question arose regarding the feasibility of funds and a coordinating committee being separated. Additional needs should be anticipated to evolve over time; there should be flexibility to change with technology. The core of services students use should be available on this one tool. The project needs to develop policy and offer security and confidentiality appropriate to doing business on campus. A software standard for providers is a consideration as well. The working group should insure and identify compatibility. A prototype will be implemented using Microsoft's SharePoint portal environment and tool set.
Voting procedures and possibilities will be discussed at the next meeting.
Back to ITPG Meeting Schedule
