(Test Load) Vendor-Related Recommendations for Test Load

Legend: not started IN PROGRESS STALLED decided

Recommendation

Provisional recommendation: AEFG recommends not adopting Shared Vendors for SILS. There are limitations in functionality that do not match UC workflows.

AEFG recommends that campuses insert CDL/NZ vendor codes into the Tertiary Reporting Code field in the Order Record for CDL content to support data gathering for CDL expenditures. CDL will provide vendor codes being used in the NZ for consortial orders.

Application of using of Tertiary Reporting Code can be investigated more in full test. This data would be inserted into purchase orders, so recommended to update order records after go-live. *NOTE: options will be explored for any campuses already using the tertiary reporting code field. As of writing, most campuses had this field free.

Given wholesale distribution of data from NZ to IZ with the “shared vendors” option, AEFG recommends deploying this job later into November in the Vanguard environment. This would allow for more coordination of usage data examples, etc. In addition, further testing may be dependent on the nature of the Sandbox environment, in particular a Premium Sandbox with UC data.

AEFG’s recommendation does not indicate any wholesale vendor record clean-up before test load.

Reasoning

See Background below regarding detailed issues on Shared Vendors. AEFG is noting Alma’s behavior in distributing, overwriting, in particular the financial system code, which is different for each SILS site, vs. a centralized purchasing model.

NOTE ON CHANGES TO VENDORS DURING TEST LOAD: Vendors are loaded once at the beginning of Full Test (from the initial extract in mid-December). New vendors created in a campuses' production environment (i.e., a new vendor is created in spring of 2021 for a purchase in FY21) will not be reloaded during the cutover extract before go-live. AEFG is developing practices for adding new vendors, that is, verifying if vendor records could get added to test to be able to match with purchase orders created in campuses outgoing ILSs. AEFG confirmed that changes to a vendor code will update the code in related purchase order records.

Background

AEFG gathered information from other consortia regarding deployment of Shared Vendors. CSU in particular, having assessed it during their migration, had still not adopted Shared Vendors at time of AEFG review.

May be useful if we rethink how we do assisted Tier 3s. Would require a more thorough review/overhaul of vendor records. The functionality that is shared does not map with how UC currently approaches its systemwide licensing. Interfaces and accounts are not shared. We would need major reconfiguring and reconceptualizing of processes. It would create duplicate and extraneous information in the campus vendor record list.

Cost data: for breakout per campuses. CDL will be able to pull that from the NZ via the funds that CDL uses to charge campuses. That reporting would be supported via an NZ_level report. For campuses: the issue would be associating local expenditures with CDL expenditures on a particular vendor. The use of the tertiary reporting code is an option for supporting this without adopting Shared Vendors.

Usage statistics: because they are connected to the vendor record, usage stats is an area - aggregated systemwide usage reporting is an area to build out. More time is needed to explore this area and application for SILS. Shared Vendors may or may not help to support this area.

Example: how much am I spending with Provider X? That may require a couple of different reports, one local IZ using that provider as the vendor code, one with CDL as vendor code and with provider code in Tertiary Reporting Code.

During Vanguard testing, it was determined that campuses have the ability to change the Vendor Code in their vendor record, and it will propagate to existing POs and Invoices. This permits a more flexible approach in the future, if its determined that reporting is better served with a consist vendor code across the system (either for all shared vendors or for a subset of high-priority CDL vendors), this is something that could be explored further, even after go live. Note that, due to the nature of shared vendors, all CDL vendors would be present in the campus vendor lists, even if only a subset of vendor records. Lastly, it may be possible to get the reporting advantages of “shared vendors” by standardizing on consistent vendor codes for records without actually using and deploying Shared vendors.

Dependencies

• Consideration of Sandbox level for testing/investigation that does not affect full test environment.

Questions to consider

• When CDL distributes network data to IZ’s, how do those show in IZ-level vendor list? Answer: If “network data” means “NZ vendor records” then Yes. (hce 1/11/2021)

• What are benefits of Shared Vendors? What are drawbacks? Answer: Primary advantage seems to be consistent reporting code and ability to share contact information about the vendor, and ability to share licenses to campuses so campuses can perform local direct purchases from these vendors. Local direct purchases from centrally negotiated licenses are not supported, regional differences often render contact information not consistent across the system and reporting advantages could be gained by local changing of vendor codes rather than incurring overhead (procedural and extraneous data) involved in sharing vendors. (hce 1/11/2021)

• Are there other ways of gaining benefits of connecting NZ and IZ activity that better match our processes? Answer: This will continue to be explored, particularly for enabling systemwide local licensing/purchase history reporting. (hce 1/11/2021)

• What is the intersection with licensing functionality? Answer: At this point, main intersection involves sharing centrally negotiated licenses to enable local campus purchasing, which is not currently a relevant scenario for UC. (hce 1/11/2021)

Action Log