| | | | | | | |
|---|
| 1 | Updates - from All-Chairs, Leadership Group, etc. | Provide updates from other SILS meetings | 21 mins | Tom | Leadership Group Tom shared back the concern about the transparency issue with Slack, LG understands and said it’s okay; they wanted to make sure that it was addressed, which we did, so we’re in good shape DOC is putting together an OA Project Team; they are reviewing the draft charge and they want to put together a nominee list that will go to OT, and we’ll look at that OT may be handing off some items to the OA Project Team Tom will have more information, as it starts to develop
Communication and the need for communication in both directions, between OT, Subteams, and LG There is no longer a communications team; OT and LG both noted this Tom dug around everyone’s kickoff presentations, and found out that OT is responsible for communication, including things such as SILS Newsletters Core responsibilities for OT related to communication: Communicating decisions to LG - doing that Ensure info from SILS Ops Center is communicated to Ops Subteams and Campus Staff - kinda happening in this group Coordinating communication from Ops Subteams and Campus Staff to LG and to CDL Ops Center - that happens here too
We’re the go-to group when it comes to operations communications We should add this to our work plan, so we can discuss a procedure or process for how we want to communicate to Subteams, the cohort, and to campuses Question: Who’s role is it if there is ever a need for something such as a town hall to update people on what all is happening in SILS? Would we still need such a meeting, or would a newsletter that includes a round-up of recent events be enough? We should consider if we want to do a town hall type of thing; something we can talk about We do need to discuss this further, maybe in the next 2-weeks, we can discuss how we want to do updates to the cohort and to all of the staff
All-Chairs Discussion about the health of Subteams, how often they’re meeting, how much work they’re accomplishing, etc. Subteams are still in the forming stage in a couple of instances, and haven’t gotten into the nitty-gritty of the work itself Otherwise, the Subteams feel pretty good with where they’re at
Ex-Libris Support Call There were some issues that Gem had brought up, where the fix date wouldn’t be until much later on What we learned in that process is that Ex Libris builds in extra time, in case things go wrong i.e. things that they say will be fixed in August, might be fixed in June So some of these are being resolved sooner than expected, and we hope that this will be the case going forward, where issues are resolved sooner rather than later
Superuser idea vs. consortial user idea Superuser can see everyone, even beyond our consortia; so ExL would like to keep this type of user to a minimum So ExL is suggesting the consortial user, which they are trying to put together, and have every campus and CDL have a consortial user ExL was reluctant to give a superuser to every campus and CDL ExL suggested Tom and Jackie be superusers for the consortia, and have things filtered through them So we pushed back a bit, and said if ExL can have the consortial user set-up relatively quickly, then we’re okay with doing this for a short while, as an interim Question re: concept of all subteam chairs also having superuser accounts, is this still on the table? Question re: difference between superuser and consortial user Consortial user can see everything within the UC (all campuses and CDL tickets), but not outside of the UC Superuser can see tickets for all other clients, beyond UC, in Salesforce
Question: are we asking to be superusers or consortial users? We want the consortial user, but that didn’t exist when we first asked for it, so ExL went back to their leadership and Salesforce and asked how can they create a user account that can see within the consortia, and limit it so that it doesn’t see all of the other clients So we’re aiming for the consortial user, but we don’t know how far out we are from ExL creating this role; ExL is checking to see how far out they are from creating this role It’s surprising that ExL hasn’t been asked about this type of consortial role previously
What ExL talked about with UCB’s bug that was related to the corrupted data issue, which prevented all of our requests from getting sent to NRLF When we submitted that ticket, ExL gave us an August fix date, but then said that was just an automated response ExL did mention that they’re going to keep working on the root cause issue, and they’re anticipating having more information in June ExL is going to work with their development team to improve the logs that are available to the support team, because that was a lynchpin issue - we couldn’t see which request failed and neither could they, and it was just one request that was holding everything up
Gem reported 2 additional issues: One from UCSD related to FTP and the files and differences they were seeing in the behavior between manual and automatic loading related to FTP Also a dedupe issue that the Discovery Operations Subteam has been testing, where there is a work around to have dedupe select the electronic record preferred, but it’s not fixing everything
ExL also mentioned that their whole CDI support team is very new, from Fall 2020 to present ExL said we are welcome to nudge them on issues when they get delayed NZ Analytics - Consortial Wide Reports The NZ Analytics was one of the whole points in the NZ ExL came back with that they need to work with support first, to figure out what is going on and whether they can fix anything; then have a general strategic discussion about that to figure out what they can do and deal with the challenges there We are waiting to hear from them on what they’re doing to help us be at least somewhat satisfied with NZ Analytics, because right now it’s not working they way it’s supposed to and it’s not working the way they said it would in the RFP process This is a big problem because now we’re in a situation where they’re not providing what they said they would provide Caitlin did want to make sure that it was clear that if we were to jump ship at some point in the future, this could be one of those reasons why we would move to something else
We still need to hear back from ExL, once they go back to their support team to discuss it further Pretty sure this will be a topic that will continue on in the monthly meetings
| | |
| 2 | Q & A Session - Including Questions on Slack since last meeting | Any questions from the team? Questions from Slack? | 1 min | Team | None from the team None from Slack
| | |
| 3 | Discuss OT Workplan | Review OT deliverables and prioritize what tasks needs to be completed first | 5 mins | Team | Work Plan 2022-2024: OT - Operations Team - SILS Phase 4 Work Handoff items for Operations Team We have a couple of things in our Work Plan, but we also have items in our Work Handoff spreadsheet Does the team want to go through the Work Handoff spreadsheet and decide what goes into our Work Plan? Or, should we put everything from the Work Handoff spreadsheet into the Work Plan, and then deal with them once they’re in the Work Plan? Does the team have a preference? Concern with dumping the handoff items into the work plan, makes it seem like we’ve decided to take them on But we could put in the notes column that we’re still determining where things go, because for at least a couple of those items, the team might decide to hand them off to another Subteam There are also some items that are done
Need to carve out some time to do this; will likely have more time next meeting, so we can discuss it further then But in the meantime, we can put in an overarching item in the work plan that says we’re working through our work handoff spreadsheet and deciding what subteams might be more appropriate for certain items, and if none, then they will be assigned to OT - Mallory will add this to the OT Work Plan
| | |
| 4 | Discuss System/Component Down Communication Path | Review and discuss strawperson doc | 18 min | Team | System/Component Down Communication Path Tom and Caitlin have added some notes, but the OT-SC wanted to get a good idea of what the rest of the team thought of it It’s a really good first step at communication strategies for this kind of situation Any comments, suggestions, thoughts, feedback from the team? When did this document come about? This came out of the emergency situation Jackie experienced with the NRLF issue, and we realized there was no documentation on how to do this kind of reporting, when there is a system down or a component down that will affect the consortia Jackie took a first pass at drafting this document, and it was reviewed in the Steering Committee (OT-SC) meeting - Tom and Caitlin helped to refine it a bit more, but there wasn’t a whole lot more to do And the OT-SC wanted to bring it to the entire OT, to ask what everyone thinks and if this is something we would want to post as something for everyone to follow
Question - Could we use yesterday’s performance issue as an example of when we would use this? Because we all get communications directly from ExL, Gem’s communication came out after the ExL communication, and we don’t want to create a scenario where CDL is doing duplicative work And with yesterday’s issue, it wasn’t super catastrophic; we had no local reports of anybody seeing any issues, which is great But ExL sent us emails, and CDL sent us emails later; every campus has a local plan for what happens if the system goes down, every campus has their own esoteric local workflow for who to notify or how to advertise when their system goes down Where does the ExL notification come in, to this document, if it’s coming out first?
Seems like we’re talking about two separate situations: This document is geared towards a local campus having a system or component down, and notifying everyone else about it Where yesterday’s issue, we were all in the same situation
Is this document addressing both of those situations? No, this document is meant to be used if you feel a local SILS-related issue may affect other campuses, including communicating to other campuses, the cohort, and reporting to ExL There isn’t specificity to the local response, this is from the local group out That is why you see the first one being the audience of ExL support and staff involved in troubleshooting, which is local or SILS cohort, whatever that might be But it’s more getting ExL involved in this situation
Okay, but maybe Gem could be absolved of her responsibility to notify us all of something we’ve already been notified of That’s outside of the scope of this document, but yes, these messages are duplicative We talked about this a bit at the last meeting, that CDL has been maintaining a list of ExL issues, and so are we all kind of, but maybe this is something else we can look into in the spirit of trying to take some things off of CDL’s plate Something to highlight for the future, if it’s just an ExL issue, maybe we can investigate are we all getting enough notification and can we let CDL off the hook for that Would be worth looking into that aspect, did feel duplicative But at the same time, Gem’s audience was the SILS Cohort channel, and not everyone on the channel subscribes to the status updates from ExL Should think about this some more, might be helpful for CDL to publish what their steps are and have some visibility on what their plans are for this situation, for a UC-wide issue
It’s a little tricky for those who are responsible for communication locally, because there are three different situations - local issue, consortial issue, or an issue that affects some campuses but not others Trying to evaluate this is sometimes a little tricky, could be a sensitive matter Difficulty with determining when to worry about an issue, and when to not Does ExL share out why issues happen when they do occur? Like with yesterday’s performance issue, will they send something out explaining what caused the issue? If they do, it’s usually not very detailed Sometimes you need to go to the status site, and really look for what is causing the issue Sometimes ExL will provide root cause analysis, but it’s usually published months after the issue
Might want to add a note to this document about confirming that the issue isn’t being caused by a local issue such as SSO issue, Network outage, etc. As we move into the Level 2 part, where it says Operations Team Rep duties, would it make sense there to really get an idea if the issue is affecting other campuses? Would that be another step we might want to put in there? Would it make more sense if the document was drafted as a step-by-step process, based on need for escalation? Start local, then consortial stakeholders, then broader audience Could see a benefit to a decision tree, especially if it’s something that we’re all planning to use
Listening to the “if, thens” it makes sense to change the document to a decision tree format, which might make it more usable Next steps: keep this document available to everyone in OT, for more discussion and suggestions for the editing, and help work it into a decision tree, then discuss it further at our next meeting This is a good springboard into other possible documents that we can provide out as helper documents to either the Subteams or other folks in the cohort
| | |
| 5 | UCOP Statistics and Analytics | Review and discuss; determine next steps | 10 mins | Tom / Team | This came up at Steering Committee, we have had a lot of questions locally about having to start thinking about UCOP statistics and what is the role of NZ in UCOP statistics? What kind of reports are they able to do? Might be valuable to discuss with the OT, UCOP statistics and whether we should have a task force or project team who addresses statistics consortially There have been whispers in this group about UCOP maybe reevaluating what statistics they ask for - what’s the status of this? There needs to be a space/group for this; we’ve talked about this before and the idea then was for it to come up organically Stats for other institutions are currently open, and UCOP is looming in September For the campuses that haven’t done these statistics before it’s been trial by fire for gathering some of these stats, such as ARL UCSC has a dashboard for UCOP statistics, and if they stay the same, Sarah is happy to show others what they’re doing This analytics group doesn’t have to meet all the time, but there are these dates by when we need to submit these statistics, and it would be healthier for all of us to collaborate, so that we’re all not re-inventing the wheel And for something like UCOP, we should all be doing it exactly the same, because then the stats are actually comparable
Jeremy’s experience at the CSU’s - someone at the President’s Office creates the reports and shares them in a shared folder There was a discussion during the first few meetings about whether John would have to get a local campus group going on figuring out how to derive ARL stats in Alma John was told no, and that ULs were being consulted on what they wanted to report out, and if they hadn’t rendered a judgment by April, then the OT and CDL would be doing it the same way we always have done it and they’d be doing it the same for all of us Didn’t know whether this was NZ analytics, or if they have permissions to get into all of our IZ’s and collect the data in the same identical way They can’t get into our IZs, and the risk there is they don’t know the eccentricities of our data, so if they did something exactly the same, it might gather something wrong
Who determines the criteria for UCOP statistics? Is it UCOP? Is CDL involved in the discussion at all? Does CDL have any say in what UCOP collects from the libraries? If so, they should revisit what data we need to collect vs. what the tool can provide Would also be helpful if UCOP gathered data that is similar to the other data that we are already collecting for other stats/surveys These don’t have a lot of overlap, so it means we’re doing two totally separate processes What’s the point of every stats gathering institution collecting stats that can’t be compared to each other?
The Steering Committee has an email that Caitlin shared with them, from Danielle Westbrook Caitlin asked Danielle about what would be the appropriate path forward for producing the statistics We know that we can’t run centralized reports for everything - that is the problem, and is the problem that came up during the most recent ExL support call From email: Not all annual stats are ILS-based, so local data submissions are still in part required even in the best-case scenario. . . we still don’t know the extent to which, at present, we can export the applicable stats from the NZ. The question to Caitlin was what the SILS Ops Center has capability of by the end of June, and what’s possible at present given the data, to run from the NZ - which we know isn’t really much So they’re trying to find out by June, what they can get But this June date doesn’t leave us a lot of time to work with, if that’s when their decision point is
Need to discuss this further when Caitlin is available to provide more information, and hopefully she’ll have an update for Danielle
| |
|
| 6 | Topics or questions for the Ex Libris Support Meeting | Any topics or questions that should be addressed at the next monthly Ex Libris Support Meeting? | 1 mins | Team | | | |
| 7 | Taking the Temperature Survey | Discuss Responses from Survey | 4 mins | Tom | Our team is pretty much inline with each other, for the most part 5 responses so far Outcomes that folks would like the team to accomplish in the next 18 months: A lot of focus on collaborative problem solving methods, as a group Communication process, how to best smooth out communication pathways Seeing us develop a strong SILS communication and process for democratically governing and advancing services Working in shared files Collaborative, communicative idea in our group
Some ideas that folks have to strengthen collaboration and communication across SILS: Develop process workflows Obtain definitives from leadership; what’s mandatory vs. optional Identify and create, where necessary, communication paths between the SILS governance structure and CKGs Zoom sessions open to all cohort members Spread the philosophy that we always need to be thinking about the big picture, especially now that we are a living consortia. Understand all the impact(s) that even one small change can make, positively, negatively, or neutrally Dream, ask, study, test, know, and communicate A lot about communication paths, identifying communication paths and starting to understand that big picture
How will we know if we are successful? Able to replicate outcomes we previously had, pre-Alma If we're able to adapt to address any problems that arise in day-to-day operations and ensure the smooth functioning Only way to know is to ask...so, regular staff and user surveys If all members on the OT feel that they have the opportunity and space to speak and express their opinion Random samples
A lot of the responses show that this team is united, so great job and we have the right team for this We’ll cover a little bit more about the What worries you? and What are you most excited about? sections when we meet next time
| | |
| 8 | Executive Session | Private discussion as needed | | | | | |
| 9 | Parking Lot | Capture important topics for future discussion | | | Communication with Subteams, Cohort, and Campuses Taking the Temperature Survey Internal Training / Training Documentation Hub Need to create a page for System Down Reporting | | |
| 10 | | | 60 mins | | | | |