Shared Services

Shared Services HLS Uses Networking IAM – Transitioned from University Service with migration of 365. Tentatively planning for to migrate HLS IAM needs to it VOIP Office 365 Canvas Security ACD Call Distribution System

Four High level Themes No common definition or expectations for the outcomes of a shared service Provider to provider model doesn’t exist Services are not Enterprise ready HUIT Services work in Silos

Theme 1: Definition and Expectation for Shared Service Shared service ≠ centralized service Attributes are being intermingled There is no consistent definition or set of expectations for a shared service. e.g. Price for IT Provider is differentiated with some services such as 365 but not Network. Individual groups are defining what they offer, how to get support, hours of operations/SLA, etc… e.g. VOIP offerings are very clear while there is no list for Security. e.g. IAM allows you to create ticket directly to them, while 365 tickets route by the service desk e.g. Network team hour are different then 365. No consistent process for managing a shared service relationship with Providers.

Theme 2: Service Desk Non HUIT Supported School’s go through same process as individual users e.g. FAS Faculty member email issue is routed the same as a HLS email issue even though HLS already did level 1/2 troubleshooting and just need someone in HUIT to push the button for something that we don’t have access too. Ticket Handling and Support Hours. General helpdesk doesn’t efficiently route provider tickets to appropriate shared services group. This issue became apparent when network team got rid of their triage group. Tickets are a hot potato amongst HUIT staff. We can see tickets bouncing between people in the same group and across multiple groups. Long resolution times that requires HLS to leverage relationships or escalate. e.g. VOIP phone setup could take 2-3 weeks Schedule of staff that resolve shared services tickets. e.g. we put in a 365 request at 3:15pm for a resource mailbox and we have to wait till the next day because team went home and only provides after hour emergency support. ServiceNow model for provider schools needs improvement e.g. For VOIP, school have to pay for a ServiceNow license so they could use the self service functionality to provision phones. i.e. we have to pay, on top of what we already do for the service, to reduce HUIT’s work load. e.g. School has to pay for a ServiceNow license to figure out the status of a ticket or to move it into the proper Shared Service group when it is incorrectly triaged.

Theme 2 Continued: Service Clarity and Maturity Definition of service, costs and what is included in them is not clear. e.g. Several of the security offerings. Services and the supporting processes are not designed with school providers in mind. e.g. Logistics of HKEY Yubi key at the school’s e.g. Getting a resource mailbox requires approval by Christian because he is HUIT’s Security Officer. Technical/Business Decisions are made without considering long term implications e.g. Work around for external users using Level 4 Sharepoint sites causes issues for all HarvardKey users that use an external email address and want to collaborate in 365 e.g. Google Tenant e.g. Certain roles prohibit 365 account to be provisioned so business units use different roles to work around limitation Processes (technical and communication) are not well defined e.g. No solution for Conference America tub billing e.g. How do we handle internal transfers at Harvard e.g. Hkey rename deletes OneDrive data bug. Example of Communication breakdown. Quality of Documentation e.g. Canvas API webservice e.g. Security offerings in general Thoroughness of Testing e.g. one of the Harvard # Exchanges for VOIP didn’t exist in system e.g. HarvardKey user self service

Theme 3: Single Points of Failure/Bottlenecks Critical Agile practices/ceremonies are not being consistently used so project experience is more Waterfall than Agile and accountability is left with individuals and not team. e.g. Blending methodologies creates problems. (365 and AD Engagement) e.g. Work is delayed or put on hold around vacation, sick days, something came up, etc... No urgency when work is agreed upon. e.g. When working on 365, HLS had to force daily stand ups to keep things moving. We are also requesting this as part of My.Harvard integration work in November. Dependency on a single person’s knowledge and access e.g. Christine in 365 e.g. Collin for Canvas feed change e.g. Dawn for ACD changes Small number of people seem to be empowered to figure things out when they don’t fall into a nice little box Jennifer on VOIP Tim G. on IAM/365

Theme 3 Continued: Lack of Automation/Value Engineering Lots of manual steps. Creates extra work and delays for groups that come from a high automation world. e.g. name changes e.g. licensing/provisioning a 365 mailbox e.g. changing a LDAP phone to local phone Lack of self service tools creates unexpected burdens and delays e.g. If HLS can’t see a student computer registration, HLS ITS has to coordinate with HUIT Helpdesk to move the registration. e.g. HLS ITS has to call HUIT Helpdesk to get a Voicemail password reset Services don’t seem to staff for known peek periods and utilize simple tools and processes to offload “easy” work. Concept of value engineering is missing. Its either all or nothing problem solving. e.g. Creating user from IAM to 365 is all manual because the edge cases require complex business rules.

Theme 4: Shared Services Groups are Individual Silos Refer to HUIT in 3rd party tense if an issue is outside their particular group. Customer has to coordinate/share info amongst HUIT groups e.g. VOIP wasn’t aware that 3905 phones were having issues. Customer has to play middle man in discussions. Nobody owns the day to day accountability with anything involving two or more groups. e.g. if something involves 365 and IAM, HLS is expected to talk to IAM and then update 365. e.g. if a switch closet is upgraded, HLS needs to ensure HUIT monitoring system is then updated.