Spotlight on Tech: How Campus Systems are Handling the UCPath Employee ID Change
In this series, we will ask different campus developers how they are handling the employee ID change. Thanks David for being our first interview!
David Triebwasser, Solutions Manager
Give us a brief description of the BearBuy application and how the employee ID plays a role in managing your business?
BearBuy is a Software as a Service (SaaS) product supported by Jaggaer (formerly SciQuest) which provides procurement features for Campus Shoppers. BearBuy supports supplier integration, product setup (hosted catalogs and punchouts), workflow for approvals, and an online shopping experience. During implementation in 2011, it was decided to use UC Berkeley PPSID (employee id) as the username for logging people into BearBuy. With the upcoming UCPath changes to Employee IDs, we need to update our internal integrations and the external account tables.
How did you start assessing the impact (if any) the UCPath employee ID change would have on your application? Were there any surprises when coming up with a plan to address the employee ID change?
We met with our technical team who support BearBuy's integration with the UC Berkeley Peoplesoft ERP. Several options were discussed and we started investigating three possible paths forward. The BearBuy team then worked with Jaggaer to determine viability. We then met with several impacted groups and scoped out each possibility:
- Integration Hub (iHub): Platform service that facilitates enterprise solutions on campus
- Berkeley Financial System (BFS): Enterprise financial application used at the University that is composed of several distinct modules, including General Ledger, Accounts Receivable, Accounts Payable, Purchasing, Billing, eBill, Commitment Control, Grants, Contracts, Project Costing, and Berkeley Integrated Budget and Staffing System (BIBS).
- Blu: Portal designed to be a one-stop employee resource for personalized access to information, services, and online resources.
Collaboratively, we compromised on the current solution.
How is the plan progressing? Any concerns about getting your application tested and ready for March 2019?
We are meeting weekly with our Jaggaer development team and have finished integrations specifications. Next up is getting our dedicated BFS system running. We are finishing integration specifications for BFS technical work this week. With any project of this nature and impact, there are concerns:
- Incorrect data mapping: Critical because users would not be able to login.
- Missing scope in BFS: Edge cases need to be covered by testing to make sure tech squad hasn't missed anything.
- Reliance on Jaggaer: They use internal IDs so this should work, but need to test.
Do you have any words of wisdom to share, and recommendations for other application owners who are also assessing and planning for the employee ID change?
- Try to involve as many stakeholders as possible. The Employee ID cuts across multiple services and business processes. End users might have a requirement we didn't consider.
- Use this project as an excuse to document underlying architecture and processes. BearBuy was implemented in 2011 and system updates/enhancements haven't been fully documented. Also, institutional knowledge was lost in the UC San Francisco/UC Berkeley split. Needed to reacquaint ourselves with how these integrations work.
- What helped us was to schedule weekly meetings with our Service partner and bi-weekly (sprint like) meetings with our Tech team. Competing projects can edge out focus especially for something this long range.
- Meet early and often!