• More user friendly (staff as well as patrons)
• User friendly OPAC, with little training needs
• Hook-to-Holdings from remote systems
• Compound documents instead of scanned images

• Modifiable code; either with source code or extensive APIs
• Global change at institution level instead of centrally at FCLA
• Concerns of basic system, quality of reports, exporting text and data
• Performance and scalability to Florida load (SUS users bang on the system very heavily)
• Don't want to switch to a system that is not as good as the one we have
• Don't lose more function than is gained
• Many of the stated wishes/needs already exist in current system
• Concern that "desired" system may not exist
• Better marketing of current functionality

• Real-time reporting
• Sorting in reports
• Local control of reports
• Call number range on reports
• Collection development and reports
• More and better reports in electronic form

Jim Corey

• This process is the most significant assignment in FCLA's 12 year history
• Committee will need a lot of help - this is a big task
• Most significant result will be a good evaluation

Big Issues

• Response time and scalability
• Can't take response time or scalability for granted
• Must be sure of getting the needed horsepower
• Need penalty clauses in contracts
• May want to do performance testing
• No source code available for some new systems
• If relational, vendors will give you some ability to access the tables
• Need to look at ability to modify but that ability is likely to be to pre-defined parameters rather than to functionality
• If pure turnkey, only input on enhancements is at vendor's customer annual meetings
• Committee must figure out how to educate and bring along all SUS library staff
• Cost is an issue and must be part of the evaluation
• We will need new money to get new system while running the existing system since there will be a period of overlap
• The union catalog requirement may limit local parameterization as the Ohio libraries found when they had to agree on parameters to be compatible with the central system and make the data synchronization work
• Discovering what functionality will be lost is a key result of the evaluation
• Need to do psychological preparation of the SUS librarians for the lost functionality
• The committee's big job is to sell the decision
• Need a spreadsheet of cost items by vendor
• Georgia found it very difficult to get accurate information from vendors
• If we must keep separate bibliographic files but keep a single view then this throws out a lot of options
• "Plug and play" may be an option, but it may be a big work effort, it may not tie together well, and it could mean a lot of finger-pointing

Architecture

• Saying client/server isn't enough, you need to specify where the processing line is drawn.
• You need to get past fuzziness of Client/server discussion and get specific
• What is on the server and what is on the client?
• In the OPAC, it appears to be the Web
• Relational is not universal in systems - some say relational is wrong for an udl while others consider it required
• If it is the Web, is it MicroSoft or anti-MicroSoft since they seem to be going in different directions?
• Java or not?

UNIX

• Unix is less reliable than the old IBM and DEC operating systems
• Unix is frustrating
• Unix is a lot cheaper
• Vendors must do value added programming to make up for lack of basic Unix function such as security
• Both Unix and NT are immature

Centralization/Decentralization

• Can we assumed we would keep a single centralized system

• Jim suggested we consider all options
• However, this could create a Pandora's Box
• The Task Force must decide how far open to leave the box
• You may leave it open through the RFI to get some idea of cost models
• The RFI can give reasons to eliminate some options

• Decentralization makes it harder
• Where do you stop decentralization -- at the institution, autonomous library and/or branch level
• If so, how do you get the union OPAC view?
• Could have any possible combination and the RFI will help to figure it out
• Don't muddy water so much that the Legislature can unmuddy it
• Isn't the legislature pushing us more and more toward cooperation? And the libraries can point to our history of working together
• If separate bibliographic files without a union catalog, the BOR will kill it
• The Legislative staff have seen a good track record from the SUS and FCLA and they won't let it go away
• BOR/Legislature won't talk to 10 universities but will talk to a single agency, FCLA. FCLA will manage it, whatever it is. (FCLA didn't assume that)
• Wouldn't rule out plug and play. Need to define terms
• The charge to the task force indicates an integrated system. Don't want any finger pointing
• We have varying degrees of systems support in libraries. Decentralization would require that all/most libraries add system support staff and that could be difficult
• They want it especially in library cooperation, especially this year in the distance learning initiative
• This goes into the cost analysis
• We just don't want to narrow options prematurely or let it appear that things are slanted to the centralized model
• Money will be a major factor in the centralized/decentralized question.

Discussion of functional requirements (Grady distributed a sample list of functions as starting point. May need to move them around then share with groups. Start as an assignment in the next couple of weeks.

• Acquisitions

• Date Capture
• Record Content and Format
• Budget
• Ordering
• Receiving
• Invoice and Payments
• History
• Reports
• Budget Tracking
• Acquisitions Lists

• Cataloging

• Data Capture
• Record Content and Format
• Record Update
• Authority Control
• Online Shelflist
• Collection Management
• Products

• Spine Labels
• Barcodes
• Reports

• Circulation
• Search
• Hold/Recall/Rush
• Reserve
• Check-out & Check-in
• Patron Files
• Fines
• Renewals
• Item Status
• Reports

• Use statistics
• Back-up

• Interlibrary Loan

• Serials

• Public Catalog
• System Administration

RFI

• Construct an RFI to gather information do if before the RFP
• RFI will tie architectural option to money
• In RFI, we need to specify the relevant data about SUS and how things are done
• The RFI will ask vendors what they can provide us
• We will need to provide vendors information related to our situation and needs
• How many vendors are able to meet our needs - nine
• Ameritech
• CGI
• DRA
• Endeavor
• ExLibris
• Geac
• Innovative Interfaces
• Sirsi
• VTLS

RFP

• For RFPs, the normal procedure is to collect examples and merge them into one big RFP with everything in it
• For the RFP evaluation process you need to write scripts detailing all the functions that need to be demonstrated to keep the vendors from slipping around system shortfalls
• Consortia are very different from a single institution and the consensus process makes the whole process much slower. Florida politics will mandate a cooperative solution
• Big private schools aren't as bound by rules as public sector schools so their RFPs may not as useful

Use of Consultants

• In using consultants, the best consultants often are users of the systems being evaluated. People get more truthful at their own sites, so site visits are important
• However, you can get people glossing over problems because they don't want to admit a mistake.

Review of Charge/Role of the Task Force

• We collect and evaluate options

• This task force is not empowered to mandate a single shared database but this is enormously important in the evaluation process
• The Task Force must make architectural choices and recommendations
• Who makes the final decisions - Directors. Charge specifies that the task force is to "review, analyze information, make a recommendation to the SUS Library Directors."

Discussion of the Process

• You can't skip steps but you can overlap some of them
• You have options on speed of process
• Nothing is forcing a decision deadline
• Unlike other NOTIS sites, we have no imperative to be off the mainframe by a certain date and we have the staff expertise to support the FCLA system indefinitely
• After reviewing the state of the market, Harvard has decided to wait as has Iowa State University
• This job has never been done in the SUS
• The CLSI experience was for a low-function system and didn't involve many who are left in the SUS; except for people who have come into the SUS libraries from other places that have been through this process, few in the SUS have experience with acquiring a library management system
• Need to establish subcommittees

• Use existing committees, before creating new ones
• Select someone from the task force to chair each functional area

• Have groups come up with a list of subfunctions
• Have someone from each university for each functional unit, if possible
• Have structure together by Joint Meeting
• At some point we need to give the subcommittees a charge
• The Task Force members volunteered to chair the following subcommittees

• Acquisitions - Rosann
• Cataloging/Authority Control -- Martha
• ILL - Sherry
• Circulation - Shixing
• Serials Control -- Janice
• OPAC/Reference Dbs/Gateways - Pam
• Collection Maintenance --John
• System Administration -- Michele/Mark

Sources of information

• Barry has information about Georgia's process

• Georgia had no single system in place; each institution had different systems or none.
• They used subgroups, held week long workshops, etc
• They had a lot of questions.
• He distributed handout #8B
• The subcommittees will break these questions out by an subdivisions
• Jim will get the OHIOLink RFP? (dated)
• Michele will check with WLRC
• Shixing will check with ILLINET
• John will check Michigan
• John will send info on the Library of Congress RFP. (They've only released Section C, just the functional spec)
• Minnesota and Wisconsin are looking for new statewide systems
• Everyone will see what they can find. If available electronically, we can put them on an ftp server. Can also scan into Acrobat

Ways for Task Force members to share information

• Grady volunteered to put info on ftp server
• Can put RFI on Web with input boxes
• Or distribute in Machine readable form on disk

Other things which need to be done

• When to have functional outline done and back to me to distribute to committees?
• We need to look at RFPs
• We should have our outlines prior to the Joint Meeting
• End of October is consensus

Discussion of Work Procedures

• When is next face to face? -- After the Joint Meeting -- Friday, Dec. 12 at UCF again
• What is our final product? Just an RFP or evaluating the responses to the RFP.
• Need to draft the set of assumptions, e.g. one bib file, one product from a single vendor, etc.
• Put minutes on the Web?
• LISTSERV archives?
• How about FCLLIST?
• Use ftp site, web site. Post message to FCLLIST when something is posted
• Could use HyperNews.
• Grady and Barry will start to flesh out the RFI structure and working assumptions

Role of FCLA

• Will assist in whatever ways possible, but needs to be clarified at some point

• Respond to RFP?
• Benchmark current functionality?
• Leave undecided RFP "bid" by FCLA until later