2021-08-17 Meeting Notes

These two organizations will discuss their delay decisions

Texas A&M -

For most of July the librarians and staff at Texas A&M University Libraries tested side-by-side processing in Voyager and FOLIO.  Any task that they performed in Voyager was repeated in FOLIO to compare the functionality and efficiency of the two systems.  Feedback was gathered informally during this exercise and from a formal survey in August.  Based on this exercise we have decided not to go live with FOLIO in September as planned.  The most significant factors are:

1. Implementation of FOLIO in mid-August of 2021 will have a significant negative impact on workflows and productivity
2. Critical functionality was not to be fixed or released until Iris Hotfix 3 which limited our ability to fully test and plan for the migration in mid-August
3. Inconsistencies with the OCLC single import and data import app made the system unreliable and inefficient
4. Data syncing and data integrity issues were still apparent in the Iris release
5. FOLIO’s lack of EDI invoicing and line limitation (an outside vendor issue & hotfix 3 timing)
6. Inconsistent fine charging along with no batch fee processing will have a negative impact on patron public relations
7. Lack of a demonstrable instance of EDS with our FOLIO data far enough in advance of our fall semester (this is an issue specific to Texas A&M, it is not a FOLIO development or functionality issue)

Here is a report with our functional area analysis related to jira tickets.

(Notes in progress:)

Tod and Christie for Chicago: 

Back in May made hard-no go decision; really been going for July. We still had concerns: partly with state of FOLIO, particularly around data import and notices + still working out our migration from OLE. Inventory and much of circ had been worked out; still other issues: data models were changing and our data is not the most straight forward. We have a wide range of integrations and didn't have enough time to work out integration with remote storage in detail. Lots of legacy (with no knowledge transfer) Microsoft Access apps automating workflows, and we are still in progress of migrating them to something that can work with FOLIO. We hadn't realised how much of a time sink those legacy apps would be, so we dcided to work on mimicking them in FOLIO first - which is not satisfying, but feels like least bad strategy.

Major challenge combining getting FOLIO up and running at same time as opening up the libraries to the public again during the summer:
1) 2 monumental transitions at same time for front line staff - so not a good option.
2) We hadn't realised how much summer time is research time and so access must be maintained.
3) The 10 days we needed to be down fell right when the uni was asking us to open.

We seemed to have automated a lot of things that peers haven't - and we needed all of those automated workflows to be transitioned. But we didn't have the staff to do that + deal with all the work arounds + reopen all at the same time → Death by a thousand cuts. Hopefully by postponing, some work arounds won't be needed anymore later on.

What influenced the original transition date? Fiscal year boundary + the ticking time bomb of aging system with few/no staff who know how to fix broken workflows (vs. a gun to head when commercial support runs out). What we want is to get past migration and transform these things into a platform we want to maintain, and it may make sense to keep some of those old apps as new FOLIO apps - we're trying to get over the gap that let's us get implemented. 

We were ok pausing some workflows for e.g. six months; the major issue was that some critical workflows (i.e. bying things, making items accessible to patrons) have to continue, and the work arounds were just too great + the instability of the workflows and troubleshooting and staff necessary for maintaining these very fragile but critical workflows - it was maybe a little too much for us. 

Paula and Beth for Texas A&M:

We still thought early July that we'd be migrating by now for live on Sept. 1st. See write up + link to specific Jira tickets affecting decision, above. (Also fyi Capacity Planing Team). We need a least some of these things fixed before going live - it's not a check list, but rather things we are monitoring and influence the decision to go-live. 

Overall we could have lived with existing functionality, if they had been functioning correctly. Also death by a thousand cuts. Just enough small critical issues→ Too taxing on staff to go at this point.  Also our FOLIO and VuFind integration wasn't going as smoothly as hoped → Impact on students and faculty, risk for negative impact was too great. 

Timing was off for end users, switching interfacing and having the time to   + deal with reoping + learning how to provide the services with new interfaces. 

We were targeting fiscal year (Sept 1.) but first week of class at same, so bad time for us! This delay decision is one of hardest decisions - we really wanted to go, but just too much pointing against ist. External factors: Voyager + creaky servers (that was a big factor of us wanting to go this year)  +  call from ExLibris who were counting on us going too... so maybe issues there too with continuing! We are going see how things look after kiwi, not sure we can make a January transition, we are considering the spring break in March - but this may depending on conversation with ExLibris. Also same issue that we have automated a lot of things; Cornell in July also moved off Voyager, and when talking with them we seemed to have more interdependencies than they did. 

Shannon for acquision: With hot fix 3, we couldn't test EDI + automated workflows for purchase oders + data import being loaded properly + troubleshooting often mutliple times  aat the same time - we needed a little more time + a little more certainty of being able to go through the whole process of ordering, invoicing, importing, getting items to patrons. 

We realised late that - we elected not to do ERM (stick to Coral until FOLIO more mature) and that had unexpected consequences. Eric: We are trying to figure out packages - we so have to implement Agreements, then eHoldings (alternative = internal KB = inmporting spreadsheets and title lists) - so trying to figure it out, we'd rather not use eHoldings app. 

We advertise FOLIo as pickand choose, but the deeper you look in, it looks much more integrated than advertised. 

Some features that aren't yet charted for dev that you'd like to see + does that influence your timeline decision? If everything we had had been working, correctly and consistently - we were willing to go with functinality in place and wait for a while for what else we need/want. Agreements from Chicago - our staff worked on the instability rather than the workaround and we werent able to absorb the maintenance of those instable workflows.

Corenell, Brooks - are these not issues for you? Missouri has few external automations. Cornell: we managed to dedicate staff to check whether our tools needed recrataeing or how FOLIO could do it. We do have quite a lot of complexity in our FOLIO instance.

Jason: not quite as big a blockers for us - Cornell opened up in phases, had staff onsite for like a year now - so we didn't have that concurrence. Also, we don't have VuFind - we use Blacklight and our dev. on it succeeded. WE do tons of automations, and they would need rebuilding whenever we went live and would be problematic; rebuilding/redeveloping that is ongoing and it wasn't sisue that it isn't all availablong on day one. We did have a moment of questioning shortly before going live (prior hot fix 2? 3). 

Paula recognises Tom Wilson from Uni Alabama, retiring in a few weeks, today is last meeting with us! Don't know who replacement is yet, but Uni Alabama is still very commited to FOLIO.