ILS
UC Berkeley Library Web UC Berkeley Library Web List of Libraries Using the Libraries How to find About the Libraries Help
Recent Changes - Search:

Steering Ctte Links

Other Links

edit SideBar

ImpDecisions

ILS Implementation Decisions

NOTE: The Implementation Team made an effort to document decisions made along the way so as to be able to provide future custodians of the catalog information about the intent behind our configuration decisions, to inform their evaluation of future adjustments. Despite our best efforts, some of the record keeping on decisions made has been retrospective. In addition, those deeply involved with the project sometimes lacked perspective about what to document. As a result, we are aware that some important decisions are probably missing from this document. We can try to remedy this as they are pointed out to us - email ils_steering@lists if you see a decision not listed here that may be of use to the ILS Steering Committee or to the Library at large in the future. Posted 7/23/10

OPAC - OskiCat

  • Continuous improvement model
Why? Allow for rapid implementation and support revisions based on use over time.
Why? Design Working Group solicited input from patron community via surveys, interviews, and initial project manager interviews with library units. Allowed for rapid implementation of OPAC design with greatest amount of user input.
  • Name suggestion finalists came from staff suggestion contest, final selection from Admin.
Why? To allow for broad input from interested parties, with final selection coming from Library leadership.
  • Logo from student logo design contest.
Why? To involve students in the final appearance of the public catalog in a way that would would hopefully attract other students.
  • Our limited slate of indexes was chosen to be used this way:
index tag "a" = author (bib and authority records)
b = barcode (item and patron records)
c = call number, LC normalization (item and holdings records)
d = subject (bib and authority records)
e = other call number (item and holdings records)
f = linked patrons (patron record)
g = government document number (bib records)
h = place of publication (bib records)
i = standard number (bib records)
j = genre/form (bib records)
k = titlekey (bib records)
l = other control number (bib records)
m = subject (resource records)
n = name (patron records)
o = control number (bib records)
p = prof/TA (course records)
q = reserved for author/title searches in the web OPAC
r = course name/number (course records)
t = title (bib and authority records)
u = ID number (patron records)
v = GLADIS number (bib, holdings and authority records) - NOTE this could eventually be used for some other purpose, once need for an indexed Gladis number no longer exists
w = reserved for keyword index
x = currently tied to SISAC checkin product
y = resource name (resource records)
z = control number/ARN (authority records)
  • Implement uniform title display/search
Why? A uniform title is assigned to a work that has no title, or has multiple valid titles, potentially in multiple languages or formats. Assigning and displaying a uniform title for these materials makes it easier for users to locate all known copies or versions of a particular item, regardless of variations in title, language, or format. This is especially important for music materials, which frequently have multiple valid titles.
  • Main entry relator code handling to separate entries by role in results screen:
Why? To allow for better user access to specific materials, the various $e relator codes/phrases ("roles") were included in the author index so that each one displays separately on the results screen, e.g.
"Twain, Mark, 1835-1910."
"Twain, Mark, 1835-1910. Associated name"
"Twain, Mark, 1835-1910. Correspondent"
"Twain, Mark, 1835-1910. Dedicatee"
"Twain, Mark, 1835-1910. former owner"

  • Post search limits page: Modeled after UCI - offer a large number of post-search options, and their grouping.
Why? There was no limit to the number of post-search options that could be included on the post-search limits page, multiple post-search limits can be selected by the user, and our data was better suited in some cases to provide reliable results with a post-search limit as opposed to a scope.
  • Language limit: special handling written to allow limit by any language in the LC language list.
Why? To allow for better user access to foreign language materials and to provide the same functionality as Pathfinder.
  • User data and feedback to drive future decisions regarding the OPAC.
Why? In recognition of the "continually beta" world in which our current patrons live and their expectations about continuous improvement.
  • Provide the scope "Available online" as a search limit.
Why? User survey indicated high interest in ability to search for online resources.
  • Provide ability to limit search results to "available items" - "available" is configured to mean any item with the status of 1) not checked out, 2) library use only, or 3) restricted.
Why? Patrons can physically access items with these statuses. In this context, available means "available to view", but not necessarily "available to checkout".
  • Highlight features unique to OskiCat: Renewal, finding course reserves, limiting to available items, limiting to a particular campus library, viewing the status of individual items.
Why? Charge indicated priority should be on services unique to OskiCat.
  • Created tab to "find articles" and link to Next Gen Melvyl within each record that has an issn/isbn.
Why? Charge recommends refering users to other systems that may be better suited to meet their needs.
  • Google books search link not implemented.
Why? Timeline didn't permit implementing before go live.
  • Book cover images not displayed.
Why? Would require additional purchase.
  • Encore federated searching and other web2.0 features not implemented.
Why? Requested by Implementation Team but rejected by Admin for cost and competition with Next Gen Melvyl concerns.
  • "More searches" separated from quick search
Why? Charge indicated design was to focus on casual or novice user. "More searches" provides search options for a more advanced user.
  • Provide access to searches by OCLC #, Gladis #, and "other record number" in staff view only.
Why? Confusing to patrons; mostly needed by staff.
  • Advanced search link presented as a link on the page instead of a tab above.
Why? Focus on casual user, not making it a tab de-emphasizes that option.
  • Help text: Go live with provisional help screen text based on other UC text as a placeholder, while UCB specific text being developed. (UCB text went in place fall 2009)
Why? Timing constraints and lack of general familiarity with the system made it impossible to create full text before going live. Fits with continuous improvement model.
  • Spellcheck implemented but suppress suggestions in the case of a search that has results (ie, suggestions offered only when zero results to a search).
Why? Part of mandate to serve needs of novice users. Suggestions suppressed if search has results because suggestions not always useful, especially if search is in another language. NOTE: spellcheck functionality limited and not modifyable.
  • Vernacular display implemented for Chinese, Japanese, Korean, Hebrew, Arabic, and Cyrillic.
Why? Sigificant collection in languages using non-Roman scripts. The scripts displayed are the ones III offers.
  • Items display sorted by location alphabetically by display name, with these exceptions: Bancroft, NRLF, archival and master negatives, and internal locations filing last.
Why? Facilitate access to available, on campus items. Allow note to be added to holdings record when holdings split between campus and NRLF directing users to look below for items at NRLF.
  • Linking location name to Library information page for that unit (floor maps, etc.)
Why? Provides patron with access details.
  • Call numbers will be indexed in two separate indexes (meaning they must be searched separately).
Why Two Separate Indexes? More than one call number index is needed in Millennium because we use more than one call number scheme. At the minimum, we're able to use two; one for LC call numbers and one for all other call numbers. Each call number scheme is formatted differently using a combination of letters, numbers, and punctuation. In order for searched call numbers to file and display in a way that makes sense to end users, a normalization rule is applied to the call number index. Normalization rules take into account letters, numbers, and punctuation, based on call number scheme attributes. Only one normalization rule can be applied per index, therefore, we require a separate index for LC values in order for them to be "read" and to file in an order which makes sense. "Other" call numbers may be comprised of any number of letters, numbers, and punctuation values, and in any order, so a different normalization scheme must be used.
Separate indexes are also required so that statistical reports based upon call numbers will make sense. Millennium contains something called a SCAT table. This table is comprised of ranges of LC call numbers based upon broad subjects, for example:
RE0000.0000-RE9999.9999 = Ophthalmology
RF0000.0000-RF9999.9999 = Otorhinalaryngology
When a circulation transaction occurs, if the item contains an LC call number (MARC tag 090), the value will be looked up in the SCAT table, and an entry will be logged. Over a period of time, we can then see what is circulating by subject range. In addition, we can also count volumes within general subject ranges. It's understood that these statistics will exclude any materials which have been cataloged using "other" call number schemes (MARC 099).
Each unique call number scheme or call number scheme with a different normalization rule at the library should reside alone in an index dedicated to its use. Storing call numbers that should have different normalization rules in the same index has implications for OPAC and Millennium display as well as statistics. Sorting in OPAC and staff browse displays may fail to work as desired. Interfiling of call numbers may not work as expected.
  • Index the call number from the attached records, not the bibliographic record.
Why?Berkeley only indexes call numbers from item and holdings records (.i and .c). This is because branch items may use a call number which is unique from another branch. For example, History of California, has been cataloged with the following LC numbers at Berkeley branches:
BANC 090\\$aE13$b.B199
BANC 090\\$aE13$b.B2
BANC 090\\$aF861$b.B22
CHIC 090\\$aF861$b.B221
MAIN 090\\$aF861$b.B3
An indexed call number in an item record applies only to that item, and an indexed call number in a holdings record applies only to that record. However, an indexed call number in a bibliographic record applies to all attached item records (except for those with an indexed call number in the item record.)
At Berkeley, indexing from attached records makes most sense, and was easiest to accomplish given our migration capabilities from GLADIS. Indexing from the bibliographic record makes most sense where all library copies use the same call number value, and where the exception (which could be indexed from an attached record) is an uncommon occurrence.

Acquisition/Serials

  • Do not migrate old historic order data from Gladis.
Why? We are running out of time and this is optional. This data was not available to query before in Gladis. Would not be easily usable, even if it were migrated. Paper trail dates back 10 years for audit.
  • Order record will display in OskiCat when an item is on order and that we will allow holds to be placed. Display orders when there is no .r. (received) date in the order record, at which point the item record displays instead of the order record in OskiCat. (Decided and approved by the Advisory Group)
Why? Facilitates patron access and notification (via patron placed holds) in an automated way. Allows patrons to know what materials have already been ordered, reducing unneeded order suggestions.
  • Order records with a "cancelled" status will not display to the public.
Why? We don't expect to receive the item and displaying it would be misleading.
  • Approved mapping for Holdings Data:
YES PRV --> 561 (in bib record)
YES BIB --> 590 (in bib record)
YES SLF --> 990 (in bib record)
YES SUM/STO/STX --> 866 0$a (in holdings record)
YES INDEX SUM (if time to parse, otherwise, same as above)
YES LAK --> 866 0$z (in holdings record)
YES UPI --> "g"
YES SUF --> 945 $c (in item record)
YES SHL --> 945 $p (in item record)
YES PI (if holdings record is already being output, otherwise, no) --> "t"
NO BND
NO CI
NO PO
NO CIR

Cataloging

NOTE: For decisions on having two separate call number indexes, and on indexing the call number from the attached (item, etc.) records instead of the bib record, see OPAC section.

  • Implementation Team will not pursue indexing the 856 field, instead will rely on using "create lists" to generate 856 content reports.
Why? Because the 856 does not contain data which can be meaningfully indexed for public use. Since searching on field 856 is generally limited to staff, it was decided that create lists would could be used instead.
  • To drop the 999 field.
Why? 999 was reserved by III for migration processing. Therefore, we needed to drop any 999 from GLADIS output.
  • To index the 590 note field.
Why? Since 590 was used by cataloging for internal notes (record level 2 and 3), there was some question as to whether this field should be indexed. After careful analysis, it was determined that 590 had also been used for notes useful to the public. Consequently, we decided that the 590 should be indexed. [NOTE: 590 cataloging notes were subsequently moved to field 900.]
  • To not index the Publisher from 260$b.
Why? Because 260$b is not entered as controlled vocabulary, a phrase indexing would not retrieve meaningful results; keyword search & post-search limiting provides more meaningful results. Limited number of indexes available.
  • To not index series in a separate index.
Why? Included in the title index. Cataloging practices/Marc format do not support a meaningful index for users. (Series is no longer a controlled entry.) Will reduce confusion for the patron. Limited number of indexes available.
  • To not index Corporate author index.
Why? Included in the author index. Do not need another index, just need a label. Limited number of indexes available.
  • To delete blind authorities and recommend outsourcing authorities maintenance to the Advisory Group.
Why? Blind authority records cause confusing results/deadlinks. Outsourcing of authority work recommended because of the lack of staff for in house work, and because for a database of our size it would be more effectively done in an automated way. The Advisory Group decided not to pursue outsourcing at time of implementation for budget reasons but could in the future. NOTE: Authority records which were blind on Gladis were not loaded to Millennium.
  • To have staff mark cataloged records (defined as having a catdate) for deletion and suppress rather than actually deleting them and that records be reviewed prior to deletion. It was agreed that temporary reserve circulation records should be marked for deletion with a note about why they are being deleted placed in the MARC record (which would suppress the record) and reviewed weekly and deleted by a centralized authority. Bib records are the most important in that deletion of bib records deletes all connected record. As soon as the bib record is suppressed, the appropriate OCLC symbol (CUY, ZAP, CBT, CBG, WCA) should be removed. Two people in Systems will have ability to delete cataloged bib records.
Why? Deletion of cataloged bibs can affect any or all of the ten cataloging units in the system. Suppression achieves the immediate need of removing the record from public view, allowing review and OCLC synchronization to happen behind the scenes before final delete. Deletion of cataloged bibs not widely distributed for data protection in an integrated system.
  • To have a Technical Processes Transitional Task Force.
Why? To do research on cataloging practices, make recommendations, and get approval from Tech Services Council (TSC). A comprehensive understanding of the migration process was necessary for the task force to function effectively as a clearinghouse for technical processes. It is in the purview of the Implementation Team to charge it:
- Dana, Ginny, and Randy wrote the charge and Charis presented to the Advisory Group for approval;
- The task force was charged as a transitional group for 6 months;
- The task force was added as standing agenda items at Technical Services Council and BTECH meetings;
- Policy decisions were referred to Technical Services Council
  • Only people in self-cataloging units, NRLF, and central technical services who actually do cataloging will be given authorization to edit cataloged bib records (records which contain a cat date). We will identify and take cataloged bib. edit authorization away from people who edit a cataloged bib. records after discussing the list at a future Imp Team meeting.
Why? Editing a bibligraphic record allows for potential destruction of essential data, and the bib record can not be protected on a field by field basis nor on a location basis as other record types can. Essential information for synchronizing with OCLC can be lost via bib edits.

NOTE: This was tabled because of administrative changes in technical services. No changes have been made yet.

  • Delay decision on bib record edit for all. To be revisited in October.
Why? There may be changes in strategy after VSO and reorganization of technical services staff.
  • To not add call number to Duplicate Checking
Why? There are serials and other needs for duplicate call numbers - you would get a warning popping up for every item added which is not efficient or necessary.
  • Number of item records per bibliographic record is not to exceed 4000
Why? System requirement. The System allows a maximum of 5,000 item records per bibliographic record. Innovative recommends the user stay below the maximum because it makes it easier to add missing items and allows room for expansion. The Migration loaded up to 3,999 item records per bibliographic record. If there were more than 3,999 items on a given Gladis records, a duplicate bibliographic record was created during the load. The result is there can be more than one bibliographic record for a given title.

Circulation/Reserves

  • Do not Go Live with Circulation during the middle of the semester.
Why? To reduce disruption to library users and staff. To reduce the risk of a system crash during peak usage periods.
  • Course reserves on Gladis will not be migrated to Millennium.
Why? Since we planned to go live at the end of a semester, it would be easier to have reserve staff put summer reserves directly in Millennium. One few thing to try to migrate.
  • Permanent reserves on Gladis will be migrated in a limited way to Millennium. If an item is on permanent reserve and bib record level is q or higher, the bib record will be migrated. Call number SUF notes (including "Reserves") will be migrated. However, the reserve status will not be migrated into the Millennium Reserves Module.
Why? Millennium Reserves are for course reserves only. LSO can transfer permanent reserve items with a "Reserves" SUF note into the unit's reserve location.
Why? To facilitate circulation staff's understanding of the loan periods. To make borrowing rules more consistent and easier for the patron to understand/predict across campus.
  • Circulation module will use a multi-branch loan rule determiner table.
Why? To accommodate subject specialty libraries loan periods.
Update These decisions were changed by the Advisory Group from what the Implementation Team initially recommended.
  • Will not use semester loan periods.
Why? Too difficult to maintain loan rule tables each semester. Approved by the Advisory Group.
  • To stop sending new invoices to CARS. Items already billed in GLADIS via CARS, but unpaid, will migrate to Millennium as checkouts with original due dates and Millennium will re-bill. There will be no migration of outstanding processing charges, binding charges, or fines (this will be an unannounced amnesty). Bill replacemenents that did not previously go to CARS will be forgiven and not migrated as checkouts to individual patrons. RFR.d material will be migrated with a note. (Approved by the Advisory Group)
Why? Allows for cleaner migration and reduce risk of double billing. Fine and billing data may be lost in the migration.
  • To only provide refund for paid items returned within 90 days of the date paid, whether or not item may have been replaced by the library. No refunds after 90 days. (Decided and approved by the Advisory Group).
Why? Millennium can't process credits to patrons. Miminize impact on LBO. Similar to standard business practices outside the Library.
  • Recently returned status to be applied uniformly (status present for 96 hours, then converts to on shelf status)
Why? To assist staff and library users with useful return information.
  • Circulation staff needing to create spine labels and minor item edits must have an individual circulation login. Only those staff (like Reserves) that need to work with the bibliographic records will get cataloging logins. Training in cataloging procedures are required.
Why? Reduce training needed by general circ staff. Reduce potential for cataloging errors.
  • To table universal return until Jan. 2010 (Decided and approved by the Advisory Group - Implementation Team recommended implementing right away)
Why? Concerns about staffing needs and funding; more information needed before final decision is made.
  • To age overdues up to the time of block during migration.
Why? So patrons won't be billed on day one after migration. Time to return tiems before billing.
  • To consider the possible use of Millennium Offline circ sometime after we go live.
Why? To be use in the case of the network being down.
  • UPDATE: We decided to do manual circulation during network downtimes.
Why? PC clocks have to be synchronized for offline circ to work. Too easy to make mistakes.
Why? There are several situations where a proxy card would have been used in the past, but can now be covered by: status codes, transfer procedure, personal cards, and special projects. Each situation needs to be addressed and sorted by the New Processes Group for new procedures, since these processes involve staff from various departments.
  • Automatic block for recall overdues even for faculty.
Why? No other option available in Millennium. Advisory Group made aware. Offers the best public service - allows us to get materials back more effectively when other patrons need them.

NRLF

  • Open NRLF item edit to NRLF approved people.
Why? Certain staff outside of NRLF need to add data to item records belonging to NRLF, for example, binding prep and conservation notes, cleaning up items belonging to branches but at NRLF. In addition, without NRLF item scoping, staff are unable to sort, transfer or link NRLF items.
  • Patrons cannot use Request feature in OPAC to request NRLF restricted items.
Why? NRLF Restricted Working Group recommended that all patron requests for NRLF restricted items be staff-mediated.
  • On OPAC, for NRLF locations with Restricted access, display the name of the owning library before NRLF location (Bancroft (NRLF) instead of the normal setup of NRLF and the campus (NRLF (UCB)).
Why? Restricted materials cannot be used at NRLF or loaned to another library. They can only be used at the owning library. This setup ensures that the patron sees the name of the owning library where they need to go to request the material.

System Set-up and Maintenance

  • Location codes:
Any location that might want discrete stats needs to be a discrete location or group of locations easily identified.
Why? Takes advantage of built-in functionality.
  • Any location that would be desired to be used as a limit, either by patrons, or in a report by staff, needs to be a discrete location or group of locations easily identified.
Why? Takes advantage of built-in functionality.
  • Location codes will not be created unless there are physical shelving locations.
Why? The purpose of the location code is to tell the patron where to find the item.
  • Locations should be grouped along administrative lines.
Why? For reporting purposes and to support Loan Rule table maintenance using wild-carding.
  • Locations should be easy to maintain/interpret.
Why? To keep staff from being confused while working with the codes.
  • Locations should be grouped by hours/days open
Why? To support maintenance of Hours Open and Days Closed tables, which determine due dates/times and fines assessed (for finable items).
  • We shouldn't create more locations than we need.
Why? Loan rule determiner table limit of 1499 lines. Overhead is a nightmare.
  • Location subloc lists need to be approved by each unit head.
Why? The lists in hand from the Holdings WG are samples and may be incomplete. Each unit head needs to be sure it is correct and complete.
  • To eliminate "peri" location from location table.
Why? Location does not exist.
  • A revised NRLF location plan that included the NRLF circ status was decided on. Group decided to move circ status to end of the location code to assist regular stats gathering, with the understanding that this makes the one time task of creating the loan rules table harder.
Why? It seemed like the best trade-off at the time. NRLF locations could be grouped by institution, owning location code, and then NRLF circ status. Loan rules could be designed to support NRLF loan rules based on institution and NRLF circ status.
  • For non-NRLF location codes, it is too difficult to group by building, administrative reporting lines, or subject area ("sciences") for the remaining libraries in a way that is fairly certain not to change over time.
Why? Desire is to have code structure that can be used for a long time into the future.
  • For non-NRLF location codes, rejected idea of dedicating first position to institution or subgroup code. Decided to use the following scheme:
Positions 1-2: two letter loc code from GLADIS four letter loc.
Position 3: Prefix, from call number prefix. Will need a translation table to convert doubles ("ff") to a single character ("g"?).
Position 4: Suffix, from standardized list of 33 or so, if possible.
Position 5: Save for future use, if possible, or use for suffix overflow if not.
Why? To facilitate wildcarding and standardize the structure of locations.
  • To "cluster" Ethnic Studies and Bancroft, but not using "E" or "B" because there are other locs that start with "E" and "B". May use something like "Q" or "X", etc.
Why? To make clustering easy. Allows wildcarding.
  • To standardize "new books" as a location and not a status or loan.
Why? New Books should be a sublocation, because a charge doesn't indicate to the public that they can come in and view the items, and being a sublocation allows units to vary in their policy about patrons ability to check out/place holds on new books materials. NOTE: This is being changed as of spring 2010 per Sciences Council and circulation services, because the location of New Books had an unacceptable workflow impact.
  • The prefix will be in the call number and location fields.
Why? Allows for labeling - system allows for a call number prefix, but the sublocation is needed if there is a special shelving area.
  • System comes with 80 review files in Create Lists module. Decided to request another 80 files.
Why? To accommodate need for list creation.
  • Approved Review Files schema:
500K (2)
100K (4)
50K (8)
20K (16)
10K (20)
5K (25)
2K (20)
1K (15)
.5K (10)

Distribution of Create Lists review files can be reviewed and revised after gaining some experience with the types of usage and level of demand.

  • Staff initials will be tied to specific authorizations but can't change broader manager-controlled preferences. Individual preferences can be changed except by members of login groups. Passwords will be changed regularly
Why? Integrity and security of the system.
  • Password Policy - With release 2007 we have some choices about Millennium password policy. The ILS Implementation Team decided on the following policy:
Passwords will expire after 360 (the maximum). Users will be warned 25 days prior expiration and be prompted to change their password. After eight (8) failed login attempts the user will be forced to re-launch the client. We will not presently require a password change upon the first login. New passwords must be different from the old ones. The password length is 8 characters (which is campus standard minimum and Millennium maximum) including at least one (1) lower case; two (2) numeric and one (1) upper case character. No non-alpha characters will be required.
Why? To comply with campus security requirements
  • To use the "new user" (view only) login, for all users, for viewing III documentation and web management reports. All users will need to use this additional "new user" login/password to use these functions.
Why? To work around password formatting issues.
  • Status Codes at implementation
CodeValueOPAC SuppressOPAC Request
(dash)AVAILABLENN
mMISSINGNN
zCLAIMS RETURNDNY
nBILLED-NOTPAIDNY
tIN TRANSITNY
sON SEARCH1NY
uON SEARCH2NY
vON SEARCH3NY
oLIB USE ONLYNN
$BILLED AND PAIDYN
[!]ON HOLDSHELFNY
wWITHDRAWNYN
iIN REPAIRNY
pIN PROCESSNY
bAT BINDERYNY
(dash)RECENTLYRETURNNN
gOUT4SCANNINGNY
4REFER4REPLACEMYN
eON EXHIBITNY
rRESTRICTEDNN
(dash)DUE [date]n/an/a
Why? Desire was to make most items that could someday become available requestable for ease of patron notification and potentially to assist replacement decisions based on number of holds.
  • Change itypes for serials to .Serial regular. and "Serial other. and length of loan time in Loan Rule Determiner table as needed to address the problem that some libraries want to set a longer loan period for older serials.
Why? Initially we set up "Serial other" as "Serial - short term". For most units, the regular serials loan is short term. Changing the label reduces confusion and the need to move serial items from one itype to another. In order to accommodate unit loan policies, only the Loan Determiner table entries would need to be changed.
  • Once implementation is done, Circulation will be handed over to Penny for day to day maintenance. Will do all circ tables, except hours.
Update Penny now handling hours tables.
Why? Easier for maintenance to be centralized in Systems, in part because troubleshooting of problems done in Systems.
  • Record maintenance procedure: Dave Z will refer individual records to Michael Meachum. LSO will do mid-level category, involving Rapid & Global updates. Eileen, Dana and Charis will take over prioritizing clean-up.
Why? Distributed model to allow for most efficient routing of record maintenance tasks along with appropriate oversight.

Training

  • Training will be organized in Room 105 Doe.
Why? Most accessible room. Also, to have a dedicated space for training.
  • Training sessions will accommodate up to 12 people.
Why? Recommended by Innovative as the best size group.
  • Staff will be required to complete training before they will receive access to Millennium.
Why? To make certain staff have basic understanding of how to use the modules to perform their tasks.
  • The basic training should enable staff to perform at least 80% of the job when they start using Millennium, training should focus on all of the basics and not dwell on the most esoteric and exceptional situations.
Why? Pareto Principle. Economy of staff and trainer time. More complex issues will be revealed with usage and can be addressed by trainers as they arise.
  • Each training module will need an initial team of 12 staff to become the trainers who will be expected to receive training, train others in 4-6 training sessions a month, initial and long term. Trainers must agree to long term responsibility, should become part of their job description, and be involved in writing the documentation.
Why? To ensure quality and consistency of training without overly taxing staff. Also a requirement, since III follows a "train the trainer" policy. re: documentation. Trainers are in the best position to write documentation. They know what staff need to know and also whether or not documentation is accurate/an effective learning tool. Trainers should have training as part of their job description to ensure supervisor approval and release time needed.

Working Groups

  • Decision to form working groups around modules and work processes. Working groups named thus far: Authorizations, NRLF, Printing, Profile Evaluation, Training, and Statistics.
Why? To involve all levels of staff in the process of determining how modules should be set up.
  • Draft Scope Statement for a working group: Profile Evaluation
Organize a Library wide process to evaluate how bibliographic, authority, and item sample data loaded into the Millennium test database. Coordinate evaluation of how the information mapped over from Gladis, how the data is indexed, how field group tags are assigned, involving a wide range of Library staff. Organize a process for submitting and responding to input from the Library community and make recommendations on feedback to the Implementation Team for possible referral to III. Coordinate Profile Evaluation training for the Library community with support from the Training Working Group. NOTE: This group is not working on OPAC display.
Why? The more staff involved in evaluation, the better our finished product. Need to call on a wide range of expertise.

General Administrative

  • To just note action items and decisions, not discussion. To note absences but not list those attending. To not use a formal approval process - please review here regularly and just correct, add comments as needed. Please post minutes by the following Monday after each meeting.
Why? To simplify administrative tasks and to reduce the time needed to do them while capturing what is important in our meetings (action items and decisions).
  • To take the time to provide complex examples in the initial load of test data, even if this pushes back the project date.
Why? It seems important to give III the range of complexity, so they/we can make good decisions about implementation.
  • INITIAL TRAINING for the Implementation Team will be July 31, 2008 -- 10:00 . 12:00; 3-DAY TRAINING will be Aug 26,27,28, 2008
Why? Agreement with III.
  • Staff authorization on Millennium - as a general rule, the lowest level of authorization will be assigned to staff members, and additional authorization will be added on an as-needed basis. Structured training, possibly requiring an official sign-off when completed, will be provided to address workflow changes as well as the new mind set required by a single integrated system.
Why? Minimize risks, control who is doing what activity, ensuring that there is adequate training, and ensuring accountability.
  • Mark will be our official Decision Czar. He'll be listening for decisions we're making during our discussions, and making sure that those decisions are announced and documented on our project wiki. A final, edited copy will be produced for official documentation.
Why Provide historical perspective of reasons for decisions made. Allows the implementation team to be able to evaluate the process and the project. It is important doing implementation to know what decisions were made and why.
  • The Last Needs session will be an Early Bird in Morrison, after the meeting with the Sciences, probably the second week in September. In advance of the Early Bird, Jemison and Silva will organize the Needs already received and make them available for all staff.
Why? To bring staff up to speed on the project.
  • Millennium Client installation needed Library-wide.
Why? Staff currently using Gladis and/or Innopac will need the Millennium client to do their work.
  • Keep the smallest gap possible between Go Live for Cataloging and for Circulation, ideally only 1-2 months.
Why? To allow circulation of newly cataloged items without having to create Q-level records on Gladis.
  • Support for the migration process needs to be the top priority throughout the Library.
Why? This is a large project that will require staff participation throughout the library.
  • Add RSS to Wiki.
Why? Convenience for those who want it.
  • Not loading our own order data into the training database
Why? Not possible
  • System down day after last day of autocirc on GLADIS for allow migration of circ data
Why? Did not have a choice. III's policy
  • Investigate other modules for possible purchase. The following modules will be investigated further. Each person will write a brief description and reason why we should purchase.
Why? - See details of what the Implementation Team recommended and WHY for each module here: http://sunsite3.berkeley.edu/wikis//ILS/index.php?n=Links.MillenniumModules
  • Additional modules were prioritized for the Advisory Group based on perceived benefit:
Essential: Patron API, Materials Booking, Deposit Collection, url Checker, Encore
Desired: All the rest, with Telephone Renewals first.
InnReach marked for future consideration.
UPDATE October 16, 2008: The Advisory Group has limited the number of additional modules to be purchased that have ongoing expenses due to budget concerns.
Why? - Imp Team prioritized them because budget concerns and implementation timeline would not allow implementing all available modules. Imp Team in best position to evaluate and recommend each module because of familiarity with Millennium and with overall Library needs and operations.
  • To seek the consulting services offered by Phil Youngholm:
Why? Phil's expertise could be helpful for duration of the project. Could use his help for the following:
1. Review and coordinate system and workflow documentation. Comment: Providing those who need to write this a template to make it easy and an incentive (someone caling to ask about it) could help them actually do it. Phil won't have local expertise to create such documentation.
2. Be present each week of going live, on site.
3. Help operations unit get scripts set up, canned reports, etc.
4. Help working groups focus their work, be a quick way to answer questions.
5. Be "on call" to answer our Millennium expertise questions quickly.
  • Affiliated libraries will be included in initial implementation and will keep their own OCLC holdings symbols
Why? Allowed to keep separate OCLC holdings symbols so these libraries can keep their ILL revenue and maintain separate OCLC identities. Included during the project instead of after so that our III implementation team would be available to help guide us in the complex process of incorporating this new record source, and so that training for Affiliated library staff can be part of general Millennium implementation training.
  • Footprints has been implemented for OskiCat Help Desk in place of Wufoo.
Why? Already supported in house.
  • The GLADIS server will be taken offline in mid-June.
Why? Overlap of both systems running circulation at the same time not possible, because of synchronization problems. Also not desirable to offer OPAC view of "stale" data - hence a full cutover required on Go Live date.
  • Adopting the draft policy/procedures re: freeing busy records.
Why? Freeing busy records is necessary but potentially dangerous and should be limited to a small group of people.
  • Freeing busy records policy/process:
A few people from each module will be authorized to free busy records. This will be publicised so staff know who to contact.
Draft Policy (for Acq/Ser): At minimum, wait overnight before freeing a record. OK for LSO to free busy records after waiting overnight if tickets come in via the OskiCat HelpDesk.
Policy for Circ could be different than Acq/Ser/Cat.
Free Busy records will remained controlled but some staff should have that ability to assist patrons with checkout.
No new staff accounts will be given Free Busy authorization.
Why? Danger is that freeing a record that is really in use will wipe out someone.s work. It may also create broken links and broken patron holds. Records are busy when they are in a payfile.
  • Circ and cataloging trainers will be the first group to receive create lists training. Naming conventions for lists will include a "save until" date, a descriptive name, and the list owner initials. Expired lists and lists that do not conform to the naming conventions can be deleted by any trained user. There will be a 24 hour grace period before lists are deleted. Training for create lists will start after the final go-live date and after the system has been in use for 2-3 months.
Why? Need a way to manage the system resources needed to run create lists. Also need to manage use of a limited number of lists.
  • The ILS Implementation Team makes final recommendations and decisions regardless of Working Group recommendations.
Why? The ILS team has the best overview of the entire project.
  • Delete Records Policy:
Almost anyone who can edit an item record will be given permission to delete item records
All other records will be marked for review then gathered into a file to be reviewed. Once reviewed, the records will be marked for deletion. LSO will gather these records into a file and delete them. Reviews will be done by the following people:
Bib records and monographic holdings records will be reviewed by Database Maintenance
Order records will reviewed and deleted by orders head.
Order records can also be deleted if not attached to a full bib or are duplicates.
Vendor records can be deleted by the payments unit.
Serials holdings will be reviewed by Serials Head
Self cataloging units will review their own records
Why? To balance accountability with ease of work flows.
  • All templates will be created and managed by the Systems Office. Staff needing templates can send a request by sending an example record indicating what fields to be set up for prompting.
Why? Templates are powerful tools. We want oversight to help reduce changes of creating bad data. Sending an example record should make it easier to create accurate templates.
  • Library users will be able to update their email address via OskiCat. Message will be displayed warning them that their update may be overwritten by subsequent loads from campus sources.
Why? When we batchload records for UCB faculty, staff, and students, we will use campus' email of record for the person. The message warns UCB patrons to update their desired email with campus. To avoid pressure on the Privileges Desk, patrons who can't update their email address with campus must be able to change it for themselves.
  • Will use the Millennium default labels for iCode 1 and iCode 2.
Why? Defaults are sufficient; no need to customize.
  • To recommend the formation of a new "ILS Council" to deal with policy decisions/ILS changes going forward.
Why? Need a group to handle continuous improvements once the Implementation Team concluded its charge.
  • To limit rapid update initially to Systems staff and a few others. May spread to a few other well trained people, including NRLF staff.
Why? Rapid update is an extremely powerful tool subject to massive errors, which consumes significant amounts of system resources. Limiting not only who has access but defining rules for when and how it can be used is intended to protect our data.
  • Access to GLADIS will be for Systems staff only after circulation "live" date. Our WIN6530 licenses expire July 1, 2009
Why? All needed data for operations will be migrated at that time.
  • Jason Schultz, Lisa Ngo and Jesse Silva selected as the group of selectors who will do create lists for other selectors. Participants may be required to pass a test before being given authorizations.
Why? Decision made by Chuck Eckman.
  • The server backup will switch from 10PM to midnight now that Circulation is live.
Why? Desirable not to run backups while units are open because backups queue up record updates.
  • Web Management Reports will have a shared login.

http://oskicat.berkeley.edu/manage.

Why? Easy and safe - there is little that can be harmed in web management reports.
  • Mark Marrow or Randy Brandt can provide authorization for Item Edits, regardless of the .home module..
Why? Authorization to edit items is a matter of training and need, not tied to specific modules.
  • Innovative will move over 240 licenses to the production server and leave 20 on the training server
Why? Still need access for a handful of people at a time on the training server, but most licences needed on production after going live.
Edit - History - Print - Recent Changes - Search
Copyright (C) The Regents of the University of California. All Rights Reserved.
Page last modified on July 23, 2010, at 08:45 PM
Server manager: contact