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.

Chicago

Tod: Back in May made hard-no go decision; really been going for July. We knew would be bit of a challenge to do that. Espeically because we knew fall would be coming - wanted to get FOLIO up and running in time for preparations for going on site. Still had concerns: partly with state of FOLIO, particularly around data import and notices. We also were still working out our migration from OLE. I think most of 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're also looking at wide range of integrations we have - didn't have enough time with remote storage, to really work that integration out in detail. One big thing we have: lots of local applications, built in Microsoft Access, original implementors are departed without knowledge transfer; they were automating workflows, and we are still in progress of migrating them to something that can work with FOLIO. Timeframe reviewing biz requirements + implementing this in new platform - would have been more valuable, but couldn't.  Then it became clear our reopening plans would happen at same time as going live with FOLIO and would impace the same front line staff (2 monumental transitions at the same time) → Moving forward in summer just wasn't a good option (project situation and our situation)

Christie: Death by a thousand cuts: we didn't have the staff to deal with all of the work arounds and the reopening at the same time + a lot of workflows for which there werent workaround - our hope was that by postponing, these workflows then have more work arounds available.

Tod: We seem to have automated a lot of things that pees havent - and so also thining staffing. And so all of this autoamted workflow has to be transitioned - and we need to the staff to do that!  _ It was clear that summer is time for research - they need that time for access! We weren't so cognisent of that particular demand.

Christie: And the 10 days we'd need to be down fell right when the uni was asking us to open - and that gap would have prevented the services we needed to provide. 

Julie: What influenced the original transition date? Tod: Fiscal year boundary is most attractive. OLE is open source - contractual arrangements around it with people hired to provide support + work for keeping existing software up to date (our systems continue to age). Analogy: Comercial system with support end = gun to your head. In our case, we have a system that is aging, there are fewer people to fix breakdowns in workflows and systematic errows - that's more like a ticking time bomb. Risk vs. discomfort. 

Texas A&M