Page Comparison

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.

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. We chose to mimick those because we don't really undestand how they work, so it's easier to keep on using them.

We need to reach into the data bases of those apps to do operations + collects data from many different source. And our strategy was to have a layer in our FOLIO reporting DB that mimicks the OLE structures, so that we don't have to do as much adapting. This was a surprise, we hadn't considered this at the beginning of the FOLIO planing. 

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.  Our staff worked on the instability rather than the workaround and we weren't able to absorb the maintenance of those instable workflows.

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 and consistently → also death by a thousand cuts. Just enough small critical issues→ Too issues while also dealing with reopening and learning how to provide the services with new interfaces → 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

FOLIO + VuFind issues: We had a great plan to abstract user search XP to our FOLIO instance. But we decided we didn't have enough resources to do that and also implement FOLIO - so pulled things back to VuFind with EDS and single search box. And we ran into issue getting FOLIO data into EDS and playing with that before the fall semester. FOLIO data is actually more robust in VuFind than Voyager data, so we're waiting for FOLIO to be ready to roll out VuFind. 

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 to see how things look after kiwiKiwi, 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 acquisionAcquision: With hot fix Hot Fix 3, we couldn't test EDI + automated workflows for purchase oders + data import being loaded properly + troubleshooting often mutliple times  aat times, all 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. No IT issues with FOLIO, the critical issues was rather around Acquisitions (PO creation, EDI, data import) - have all these different types of aquitions  with consistency and certainty of being to successfully get through the whole process. Staff frustration at having to go back, sometimes several times and check that something worked.  Cornell is focusing on fixing the acquisition workflows, and there are bunch of other things they're not doing to support that. 

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

We advertise FOLIo as pickand FOLIO is advertised as pick and choose, but the deeper you look in, the more 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 fron Cornell: not quite as big a as 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 We do tons of automations, and they would need rebuilding whenever we went live and would be problematic; rebuilding. Rebuilding/redeveloping that is ongoing and it wasn't sisue issue that it isn't all availablong availabe all on day one. We did have a moment of questioning shortly before going live (prior to hot fix 2? 3?). 

Phil from Cornell: We had have strong integration team (accounting export and patron import) and we were able to leverage some of their time to help. It's not perfect, we're ironing issues as they come. We know we can enact change by being a good community member, but there is still loads of things missing that we would want - but the library has still kept going. We haven't yet hit a semester yet. Big highligh: getting our DtoD stuff sorted - thanks community for helping us get that sorted out!   ((Relay-OCLC ILL Consortium platform - integration in Voyager that needed recrateing in FOLIO - and was learning on the fly) . (BorrowDirect is an ILL consortium, Relais is the software several consortia use.).

Did Cornell do comparison workflows (Voyager vs. FOLIO)? Not as an assessment tool, rather to support training. No IT issues, the critical issues was rather around Acquisitions (PO creation, EDI, data import) - have all these different types of aquitions  with consistency and certainty of being to successfully get through the whole process. Staff frustration at having to go back, sometimes several times and check that something worked.  Cornell: is focusing on fixing the acquisition workflows, and I bunch of other things we're not doing to support that. 

Ann-Marie: Important to try out your work processes in FOLIO - see if you can figure it out! That's one of most important ways to get to feel comfortable with system and see if it's meeting your needs. Those who develop can only go so far until we need feedback from people who use system every day - that's why implementers' experience are so valuable.

FOLIO + VuFind issues: We had a great plan to abstract user search XP to our FOLIO instance. But we decided we didn't have enough resources to do that and also implement FOLIO - so pulled things back to VuFind with EDS and single search box. And we ran into issue getting FOLIO data into EDS and playing with that before the fall semester.

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. We chose to mimick those because we don't really undestand how they work, so it's easier to keep on using them.