|
|
Endeavor Implementation Project |
All people in orientation training should have clients installed on their PCs soon after orientation training.
May be able to do modular training all in two weeks instead of the four weeks presently scheduled.
If possible, have trainers pound on the product after functional training and then do some consultation training on work flows.
Have trainers be the first to take functional training so they can get into pounding on the system.
Collect all of the exercises used by Endeavor in functional training so we can use them for line training later. Need to refresh training database periodically so exercises will work. Get "refresh script" from Endeavor for Systems to use.
April-May will be heavy workload for trainers and people making decisions.
June will be heavy workload for trainers doing line training.
Macro software will be helpful on PCs, e.g. checking in a serial could go from the current six button clicks to one. Product mentioned by Endeavor: MacroExpress; by Maui: EasyMacro.
If we use macros in processing areas, what is the impact on training? Endeavor does not train on locally created macros.
Check Tab 8 in project planning binder for functional training room requirements.
Windows training: use contests and games to keep staff using Windows on a daily basis. Make it part of work; require "playing" with Windows, e.g. play Solitaire.
Have staff practice searching other Endeavor sites like Library of Congress and Georgia system to answer searching or contest questions. Use Endeavor customer list to find other sites.
Functional training: -will have two different trainers -train systems staff and trainers first -then project teams -followed by staff: original cataloging (who in turn can train copy cataloging); circulation staff with full access (who in turn can train circulation staff with partial access); acquisitions staff with financial access; acquisition staff who do purchase orders; serials staff with full access (who in turn can train serials staff who do checkin only); staff who do invoicing and payments; staff web searching; public web searching (for staff and public); reserve; booking (short loan)
Trainers: focus on learning the product in the first two weeks; observe the training procedure during the second two weeks.
First modular training shouldbe on acquisitions.
For modular, plan based on number of people and number of sites to be trained. Does each site need each kind of training? Do we need a key trainer for each island?
Line training: minimize time between training and live use of system; provide weekly exercises to keep staff using the product.
Opening day needs: cataloging, circulation, web - can start general staff training on these after functional training.
What training can be distributed to the sites? - for circulation so they can set up their policies (much of circulation isbasedon local policies so let each site, so let each site train their own staffs. Searching iskey training need for all modules Circulation needs searching training for times when barcodes donŐt scan).
Provide advanced training later, especially for cataloging and authorities.
Could take one week of Modular training for Functional training for other islands?
Have one person from each site in functional training for each module especially for circulation.
Sites who donŐt use Serials/Acquisitions in CARL - donŐt need to train them on acquisitions and serials until version 2000 (wonŐt have to deal with acquisitions loads); do train these sites on setting up vendors so they can start creating vendors files.
Training manuals of Endeavor libraries are on From Our Customers page.
Read the implementation checklist being posted to SupportWeb soon.
The new version of New Customer Setup information is at: http://support.endinfosys.com/cgi-bin/validate/enter.cgi?page=Simba/Newhelp/milestones/milestones.htm
Current version is at: http://support.endinfosys.com/cgi-bin/validate/enter.cgi?page=Simba/Newhelp/milestones.htm
Read Voyager-L archives for training ideas.
There is a sysadmin-l listser that is separate from voyager-l (Endeavor staff are not allowed into the sysadmin list.
We have to be under Support, i.e. out of implementation phase, before we can upgrade to version 2000.
Have to formalize how we will distribute clients to sites.
How many times do we want public to have to adjust to changes in first six months? We could use defaults for version 99.1 and then do our local customizations when we upgrade to version 2000.
Christmas might be the best time to upgrade to version 2000, especially for public.
If we find that we cannot match our work flows to Endeavor, ask project manager if there is a way. Don't make work flow decisions until after functional or modular training.
Web catalog is optimized for use with Microsoft Internet Explorer.
Provide to other sites information about how Manoa sets public Pcs for security, browser, virus protection, etc. Consistent set up may ease support.
If donŐt get "Training Workbook," ask for it (itŐs auxiliary material)
Schedule training on Image Server - when to do? May need to shift modular training to include Image Server training earlier?
Create a group to work full-time on training and become an expert in an area.
Check vacations, minimize authorized leaves, community college staff off for summer, do not schedule training during periods of reviewing test loads.
March: planning, scheduling, look at SupportWeb and Voyager-L (threats on manuals and training), PC/technical training, staff Windows training, determine what we will no longer support in CARL in April-June.
April-May: attend functional training starting April 11, playing, prepare training materials, get work flows from units (given short time frame, may be better to provide standard work flows, avoid options and use EndeavorŐs standard training with addition of more practical exercises)
May-June: train staff, especially in June (no training when reviewing test loads); develop work flows in June if do standard training with no special work flow development in May
Project manager needs to give us information on what LTI does and how.
Need a profile for each library - what processing does each library want. HML will use MESH subjects.
Endeavor can provide recommended options.
We get lists of headings, by database, that arenŐt authorized; we can do what we want with it.
We are not extracting any authorities from CARL and loading them.
We fill out an authority profile sheet for each Voyager database.
Endeavor needs to know the number of databases and size.
If we combine databases, need to do before records go to LTI. Endeavor receives our extracted records and dedupes/processes combined databases before the records go to LTI.
The LTI work takes four-six weeks.
We have to implement gap procedures between the final extract for LTI and live production use of Cataloging. There can be no changes tobibliographic records once they are sent to LTI. Can stop cataloging; catalog elsewhere and keep a data file; continue adding record in CARL and extract later all records added during gap period.
An alternative is to load LTI-processed bibliographic records after production load of non-authorized bib records: better because no gap period and more time to see data migration problems.
Alternative A: Authorized by LTI early on, six week gap period, one extract (no test load extract) - higher risk of getting extract right
Alternative B: Do a test extract/load and a non-authorized production extract/load, then send to LTI - called "top up" load (authorized bibls over current and load authorities. Can change headings and items. Two-three week gap. CanŐt change any bib records for six weeks after load.
For B, the fewer databases the better; extra cost of about $1,500 per database.
Smaller databases might do A; larger, B - depends on whether loading orders; mainly an issue for combined databases.
Risks of doing it too fast is critical with deduped databases.
Have to have functional training to obtain skills to review test extracts.
Finish cataloging backlogs by mid-April.
Seems wise to change go live date to August 1 for larger databases.
Appendicies in System Administration manual answer cataloging questions about what can do with certain tags.
Project manager needs to get a feel for A and B; in not sure, choose A because will develop a calendar with a tighter schedule.
Timed with test loads for acquisitions.
Identify what fields to map to
Accessories Manual has copy of invoice. SupportWeb has copy of purchase order report.
Need to know how receiving now.
Need to see a full sample of records early (ftp to ftp.endinfosys.com; login as "anonymous"; password is email username; cd /incoming/hawaii
ISSNs have to be good.
Wilson databases on our server as an example of citation database (will give us port number to connect to); use as possible model; look at way itŐs indexed.
The way citation server works, HPJI citations and other bib records may be retrieved in searches because uses bib record for journal; test search Wilson indexes to see if we can search just the articles without retrieving training database records as well. Need to know if we can limit retrieval to HPJI records.
Look at Auburn University, University of Alabama, New ZealandMaori index (Lynette to find out if we can access, otherwise ask Project manager for NZ contacts)
Could be scheduled to go live later.
Acquisitions Loads: need to wait on PO Receiving Report decisions.
If acquisitions orders are to load, each must have a corresponding MARC bib record; CARL orders do not have MARC records (BID # may help solve this problem); same issue in Circulation.
Vendor: use internal library code or University vendor code consistently.
Combined database has one vendor file that cannot be secured by library.
Purchase Order loads: "Order location" code is where the work happens, code has to identify institutions. "Vendor" code has to match vendor code in Vendor SIFF.
If dedupe a combined database, Manoa orders win, otherŐs donŐt load.
Put status of order from CARL into notes field if want to know the original status (open, claimed, etc.). In Voyager, all orders load as "pending" so original status is lost.
Will only load prices in US$; can never change to another currency once loaded.
Serials: Serial holdings moves to a holdings record (tied to location).
Will be a gap with checked-in issues. How late can we extract and load?
Historical orders: do we need?
Serials payment history: need purchase order to attach to serials; will create purchase orders and could put order payments information into PO note. Could use repeating 9xx tags in bib records - can search and report these, or can put in holdings record, or move to an Access database. (Princeton is doing something similar.)
Circulation: Systems has to connect registrarŐs output to Endeavor SIFF.
Circulation calendar in Endeavor has to go back far enough to catch all loans (1990).
Fine Archive: need to give sample and Endeavor needs to put into development queue.
Other Patron History: we could not idenify what this was intended to cover.
Course Reserve: can load professorsŐ names, course numbers, other information.
Non-CARL serials: Hilo, HML, Ccs - postpone implementation until later.
Image Server: need to know cataloging; Cataloging has to be live. PC client called "Simtrix" make links between bib file and image file, gives image ID; loads an 856 that contains the ID.
Test images linking in bib database during test load.
Give questions re Image Server to Wil to forward to project manager. Normally get trained, then start using client.
TTPI: will remain a separate database. Images are public. Indexing will be keyword; left anchored searching can be useful for reporting purposes. Better to schedule TTPI and Image Server later because of tight time frame.
Should stop building 856 in TTPI as have been doing.
Functional committees: use as communication channels and become a knowledge base.
Channel all questions through committees (have Manoa and non-Manoa co-chairs); then through Systems.
Forward questions not answered by committees to Systems, then to project manager
Protect Systems staff who will be very busy.
Find ways to communicate information, e.g. Web-based forum software, listserv (can non-UH library staff access?)
Conference call every week with Project manager and Donna; rotate among committees so a different one participates in call each week; give agenda to project manager before call.
Get everyone throughout system to participate to "own" the project; other islands can participate via email and Web.
Get non-Manoa libraries to take over managing some of the communication.
Minutes and summaries of meetings: who needs to see?
Do updates of what is accomplished weekly.
Need sample data
Project manager will send file format in March.
Options for extract are:
1. delimited (allows variable field length; any delimiter may be used; fixed
number of fields per record) 2. Fixed length 3. Labeled (may be easiest; e.g.,
title=xxxxxxx
Need list of fields in order for 1 and 2, delimiting character for 1, field length for 2, where do we want the fields mapped to (can use defaults).
Combine BRL with Maui CC makes most sense.
Hardware training in next few weeks; includes server and client; have various library techies attend; Jorge will conduct training
Data conversion work starts two weeks after orientation; some decisions are made earlier.
LTI authorities processing must be at least four weeks prior to production load.
Can send cataloging gap file to LTI if we choose (more $)
March-April: busy with decisions re all data May: test loads
April-May-June: after functional training, focus shifts to work flow and training
How do staff keep skills learned up-to-date between end of training and live use?
Can set up passwords to allow each site to do its own reports; don't use SQLPlus because of data security problems
Web: need to copy your customized files as they get overwritten during updates
Do we want a common look and feel for web catalogs?
Set up firewall between application server and main server
Application server: staff and public enter here; reports done here; Web server is here
Main server: data loads; Endeavor enters here
Version 2000: look and feel of circ, acq and Web changing because going to 32-bit
Web: each database can have its own web interface; who will we allow to make changes? Site coordinator or Systems? Each group of sites (sharing database) should be able to make its own changes to Web
With "virtual web hosts" each library can have its own web cat frontend in a shared database
What happens on server: bib database, jobs (sites make timing decisions re circ, acq, cat and report jobs), bulk import, MARC export, other
PC: client software, each group of sites can configure its own reports, own MARC tags in separate tables by library; each department can have its own report formats; each library gets its own cataloging templates (PC specific); the file voyagerconfig.exe can be configured from PC to PC
Can put Windows OPAC client on staff machines to have more control in searching and set up (although OPAC client is not been developed further)
People who do web design can test ideas in Windows OPAC client first
HPJI may involve more than one test load.
Loading acq open orders: if bib record for order is not loaded first, the orher will not load. We need to evaluate how to set up ledgers and funds based on Voyager functionality.
It is better to load continuation orders than not.
The timing of when a site goes live depends on the loads needed, i.e. some sites can go live earlier than others.
Date of going live to public will be different than go live date for staff functions (except maybe Circ).
Don't try to go live in all modules at once.
Cutover Circ at the very end.
Cannot use Serials without purchase orders; can set up dummy ledgers as a workaround for sites that don't use POs for serials.
In shared database: if have separate patron groups by library, can secure personal information so one library cannot see another library's confidential patron information.
Can secure based on owning library who can edit a bib or holding record.
Can secure circ and acq based on library.
You can have different versions of a record
In System Administration module, you have to make some glob al decisions and can make some individual decisions
Patron can see all of his information in all libraries in a shared environment. With separate databases, patron has to look up her information in each database separtately.
In a deduped, shared database, holds, recalls and call slips are easier. These things are most complex in a non-deduped, shared database.
Patron blocks work by library.
Holdings record is owned by a library with holdings.
In a shared database, access to a web site via a hot link in a bib record (URL in an 856 MARC tag) cannot be secured. Anyone using the catalog can get to it. We would have to strip out the 856 data during conversion for records that have licensing restrictions. Can create a separate database of remote links via 856 tag.
If a licensed database is a link on main page, then can require login.
Comments to Wil Frost, Head, Library Information Technology Division, University of Hawai'i at Manoa Library, 2550 The Mall, Honolulu, Hawaii 96822 USA. Last modified: March 8, 2000.