user support services recommendation · 2019-05-09 · 4.2 call center ... manager information...

USER SUPPORT SERVICES RECOMMENDATION A Transform IT Project April 2019

User Support Services Recommendation – April 2019

1

Table of Contents

Executive Summary ............................................................................................................... 3

Project Scope ......................................................................................................................... 3

User Support Services Scope ..........................................................................................................3

Recommendation Scope .................................................................................................................3

Out of Scope ..................................................................................................................................3

Approach .............................................................................................................................. 4

Focus Group Members ...................................................................................................................4

Step 1 - Document Current Delivery Models ...................................................................................5

Step 2 – Recommend Delivery Model .............................................................................................5

Step 3 – Recommend Support Model ..............................................................................................6

Step 4 – Recommend Extended Hours/Online Support ....................................................................6

Step 5 – Recommend Geographical Locations .................................................................................6

Recommendations ................................................................................................................. 6

1.0 Recommended Delivery Models ...............................................................................................6 1.1 Polices and Processes .................................................................................................................................... 6 1.2 Technology & Tools ....................................................................................................................................... 9 1.3 People ............................................................................................................................................................ 9

2.0 Recommended Support Models .............................................................................................. 10 2.1 Service Desk Contact Points ........................................................................................................................ 10 2.2 Support Tiers ............................................................................................................................................... 10 2.3 Service Level Expectations .......................................................................................................................... 13

3.0 Recommended Hours and Online Support ............................................................................... 13 3.1 Business Hours ............................................................................................................................................. 13 3.2 Extended Hours and Online Support .......................................................................................................... 13 3.3 Hours Between Terms ................................................................................................................................. 14

4.0 Recommended Geographical Locations ................................................................................... 14 4.1 Physical Locations ........................................................................................................................................ 14 4.2 Call Center.................................................................................................................................................... 15 4.3 Off-Campus Support .................................................................................................................................... 15

5.0 Focus Group Specific Recommendations ................................................................................. 15 5.1 Accounts & Access ....................................................................................................................................... 15 5.2 Knowledge Management ............................................................................................................................ 16 5.3 Lab Management ......................................................................................................................................... 16

6.0 Other Recommendations ........................................................................................................ 18

Next Steps ........................................................................................................................... 19

Appendices .......................................................................................................................... 20

Appendix A - Links to Data Gathered from Step 1 .......................................................................... 20


2

Appendix B - Step 1 Stakeholders ................................................................................................. 20

Appendix C - Glossary .................................................................................................................. 22

Appendix D - Core, Common, and Unique Services ........................................................................ 24

Appendix E - Data Used for Geographical Locations ...................................................................... 27

Appendix F – UO Code of Responsibility for Security and Confidentiality of Records and Files ........ 28

Appendix G - Read-only Identity Management System Access Proposal ......................................... 29

Appendix H – Focus Group Reports ............................................................................................... 30

Appendix I – Implementation Considerations ............................................................................... 30


3

Executive Summary Following the Campus Engagement Project, the User Support Services (USS) recommendation project is the second project in the Transform IT program. This project is broken up into two phases: recommendation for how USS should be delivered to campus and the implementation of USS. This report outlines the recommendation for USS. Upon approval, the USS project will follow through with implementing the proposed recommendations. The User Support Services recommendation aims to increase efficient use of IT support resources, drastically reduce or eliminate duplication of user support for IT services, and consolidate support tools, processes, and services. Through USS, IT support should be provided to campus in a way that creates a consistent user experience for all students, faculty, and staff. The recommendations in this report were developed with an eye towards how efficiencies could be gained by adjusting how IT services are provided while remaining agile, innovative, and not reducing existing levels of service.

Project Scope User Support Services Scope User Support Services includes:

• Service Desk (help desk and desktop support) • Computer lab management • Knowledge management • Accounts and access

See Appendix C - Glossary for more information about what each area covers. Recommendation Scope Deliverables of the User Support Services recommendation consists of:

• Recommend service level definitions • Document service delivery models in all units today • Recommend single delivery model for campus • Recommend approach for escalated service and support • Recommend help desk geographical distribution • Include assumption of extended hours/chat support for online education

Out of Scope

• Organization structure and staffing changes. o While development of a new organization structure or recommending staffing

changes is out of scope for the project team, it is expected that the Chief Information Officer, in collaboration with campus IT governance, will recommend a new organizational structure to support adopted recommendations.


4

Approach In order to develop a recommendation for User Support Services, 27 subject matter experts (SMEs) from 13 different departments were identified and divided into four focus groups based on their expertise. The focus groups were aligned to the USS scope: service desk, lab management, knowledge management, and accounts and access. Focus Group Members Focus Group Member Title Department Project Mgmt Office

Garron Hale Senior Enterprise IT Project Manager

Information Services

Kelsey Lunsmann IT Business Analyst Information Services Accounts and Access

Michael Walsh System Administrator & Banner Analyst

Business Affairs Office

Dave Roberts Operating System & Network Analyst

Finance & Administration

Sandra Lee Technology Access and Support Specialist

Information Services

Mark Messenger IT Security Analyst Information Services Jillian Sallaway Technology Access and

Support Specialist Information Services

Charles Hollands Information Technology Consultant

University Health Center

Knowledge Management

Jody Bleisch System Administrator Business Affairs Office Mike Moresi Training Specialist CASIT Sean Sharp IT Manager College of Design Shannon Rose Executive Assistant to the Vice

President Division of Student Life

Tim Miller Director of Information Technology Services

Finance & Administration

Guy Eckelberger Information Technology Director

School of Music and Dance

Douglas Hethmon Assistant Director for Information Technology

University Housing

Lab Management

Chad Little CASIT SSIL Labs Manager CASIT Jason Shirley Systems Administrator College of Design Michael Suskin Operating System & Network

Analyst Lundquist College of Business

Ryan Stasel IT Operations Manager School of Journalism and Communication

Pat Best Computer Support Specialist UO Libraries Samuel Villalobos Library Technology Services

Student Supervisor UO Libraries


5

Service Desk Eric Ledford User Support Technologist Advancement Sam Crow CASIT Help Desk Manager CASIT Michelle Brown Assistant Director of Systems

& Infrastructure Division of Student Life

Ben Heiken Technology Support Specialist Information Services Martin Abair Technology Service Desk

Coordinator Information Services

Karl Owens Operating System & Network Analyst

Lundquist College of Business

Dave Peterson Classroom Technology Specialist

UO Libraries

Peter Verrey Operating System & Network Analyst

UO Libraries

Each focus group walked through five steps to develop a recommendation for their respective focus. The steps were aligned to the recommendation scope, as appropriate for the focus area:

1. Document service delivery models in all units today 2. Recommend single delivery model for campus 3. Recommend approach for escalated service and support and recommend service level

definitions 4. Include assumption of extended hours/chat support for online education 5. Recommend help desk geographical distribution

Step 1 - Document Current Delivery Models

• Focus groups reviewed data collected for the Campus Engagement Report for their respective focuses.

• Each focus group determined if they needed to collect additional information in order to help their group make a recommendation.

• If additional data needed to be gathered, each focus group developed a set of questions to ask stakeholders.

• Qualtrics surveys with questions were developed and emailed to stakeholders the focus group identified.

• Data gathered from Qualtrics survey was reviewed by focus groups in preparation for step 2.

o See Appendix A - Links to Data Gathered from Step 1. Step 2 – Recommend Delivery Model

• Based on the data gathered from the Campus Engagement Report and the USS Qualtrics survey, focus groups organized the data into three categories: core, common, and unique.

o See Appendix C - Glossary for the definitions of core, common, and unique.


6

Step 3 – Recommend Support Model • Focus groups developed a support model for the recommended delivery model

developed in step 2. • Support model included both how support will be provided and who is going to provide

the different types of support. Step 4 – Recommend Extended Hours/Online Support

• Focus groups discussed potential recommendations for extended hours and online education support.

• After learning that the Information Services Technology Service Desk will be offering phone and ticketing support 20x7 starting in Fall 2019 to support existing and new online education programs, focus groups agreed the USS recommendation should be in alignment with this direction and no further discussion was had on this topic.

o See the “4.0 Recommended Geographical Locations” section below. Step 5 – Recommend Geographical Locations

• Focus groups considered examples, campus survey maps, and high-traffic visible areas. o The Accounts and Access focus group collected additional data to help inform

their decision. See Appendix E - Data Used for Geographical Locations. • Recommended locations from each focus group were compiled to identify where there

was alignment and differences between the focus groups. • A campus map with the compiled locations was shared with the all the focus groups to

come up with a group-wide recommendation.

Recommendations 1.0 Recommended Delivery Models An IT delivery model is made up of the technology (e.g. tools, applications, etc.), policies, processes, and people that are required to deliver and support IT services. Below is our general recommended delivery model for USS that includes policies, processes, technologies, and people.

• More specific delivery model details for each of the focus groups can be found in their respective subsections below.

1.1 Polices and Processes 1.1.1 IT Services

• IT services should be grouped into core, common, and unique categories per the definitions found in Appendix C - Glossary.

o See Appendix D - Core, Common, and Unique Services for how IT services identified as part of this project have been grouped.


7

• The current service catalog in the UO Service Portal should be revised and expanded to accommodate the new scope of services supported. Revisions to the service catalog should be part of a continual improvement process.

• All services supported by USS should have detailed and comprehensive support plans to be able to effectively troubleshoot and triage/escalate service requests.

• USS should offer IT consultation for departments when they want to stand up a new service. Consultation would provide information about existing services that may meet department needs, recommended solutions, and help review requirements for a new service.

1.1.2 IT Support

• The service desk model should become the single point of entry for all faculty, students, staff, and UO guests/public to request IT support and access for all core and common services. The service desk should be able to provide intake and escalation/routing for unique services. This will require knowledge and documentation of where unique service requests should be routed.

• IT support staff that are not homed at a physical service desk should be distributed across campus in support “zones” to facilitate direct deskside and specialized IT support to faculty and staff in close proximity. Due to the complex nature of this delivery model, we did not identify specific zones. We expect that a future implementation team will determine the specific zone boundaries and staffing in the zones that meets or exceeds best practices for ratios of support staff to end-users or devices.

• Exchange permissions should be expanded to allow zone IT staff to accomplish daily support tasks without needing to escalate to another resource. IT staff in zones will better understand local business needs and this model will allow faster support to be delivered. Staff should receive training on both the tools and policy prior to granting expanded permissions. Additionally, staff should be asked periodically to validate their knowledge of the tools and policy to maintain access.

• Administrative rights to file server storage spaces for individuals should be granted to zone IT staff. Administrative rights should be audited on a regular basis and all actions should be logged to the central SIEM. Additionally, individual storage spaces should be auto-provisioned for new employees.

• When USS staff work on a user’s personal device, the customer should sign a service level agreement in order to protect the university from liability.

1.1.3 Desktop & Lab Management

• Specifications for hardware (e.g. laptops, desktops, printers, lab computers, mobile devices, etc.) purchased/owned by the UO should be standardized. Through standardization, support efficiencies would be gained by reducing the portfolio of hardware supported and it would allow the university to leverage its purchasing power to buy hardware in bulk resulting in cost savings.

• All UO purchased/owned hardware should be managed centrally by an Enterprise Device Management (EDM) team. At a high-level, EDM should be responsible for the


8

hardware consulting, purchasing/ordering, imaging, repair, deployment, and client management of UO purchased/owned hardware. The following should be considered as part of EDM:

o All UO purchased/owned hardware should be in a central asset management tool for inventory, tracking, and lifecycle management.

o All computers should be imaged using a baseline image from a defined standard image set and use a standard set of client management tools (e.g. SCCM and Jamf).

o Administration of client management tools should be handled by EDM staff. o EDM staff should manage licensing servers (e.g. SPSS, SAS, ArcGIS, etc.), backup

software (e.g. CrashPlan), and antivirus software (e.g. McAfee EPO). o EDM staff should manage UO purchased/owned mobile devices (e.g. cell phones,

tablets, etc.). This includes purchasing devices through PCS approved vendors and management using a standard set of client management tools (e.g. Jamf or MDM).

o A hardware refresh schedule should be established for lifecycle management. o Hardware management should be centralized in one location and staffed by one

team. o Adequate transportation for delivering and collecting hardware is required.

• Lab management should be a subset of EDM and should be managed by the same group and framework. Lab management does not need to be distributed across support zones or services desks. The management of labs should be handled in the same central location as EDM to simplify management and coordination.

o See the “Lab Management” section below for additional lab management recommendations.

1.1.4 Printing

• Supplies and printer servicing should be handled by CTX or whomever maintains the central campus printing contract.

o See the “Lab Management” section below for additional recommendations around pay-to-print services.

1.1.5 Knowledge Management

• Knowledge Centered Support (KCS) is the recommended methodology for knowledge management. KCS is a commonly adopted methodology in higher education because it allows support organizations to scale and extend their support capabilities without increasing staff or budget resources. KCS focuses on creating content based on demand and usage, then reusing and improving the content – a simple and successful formula for knowledge management.

o See the “Knowledge Management” section below for additional knowledge management recommendations.


9

1.1.6 Continual Improvement • A continuous improvement and feedback process should be developed for USS. USS

delivery and support models should be agile and adaptive. • Metrics for all areas of USS should be defined to help understand and measure success.

1.2 Technology & Tools

• All IT staff should be in a central ticketing system (e.g. the UO Service Portal). • USS support staff need a powerful and user-friendly remote support and chat tool that

is compatible with all supported platforms (e.g. Bomgar). • A central asset management tool should be identified and implemented as part of the

USS implementation. Asset management information should be integrated with the ticketing system.

1.3 People 1.3.1 USS Staff

• United under one organizational structure, User Support Services should become a group of dedicated IT staff who support the service desk, accounts and access, lab management, and knowledge management functions, processes, and services for IT on campus.

• The number of required staff to support the functions of USS should be identified using a ratio that meets or exceeds industry standards.

• Going forward, metrics should be developed to adjust zone staffing and redistribute as needed. For example, the ratio being used to help determine the number of required staff may need to be adjusted in the future based on data.

1.3.2 Student Employees

• Hiring, training, and management (e.g. evaluation, promotion, expectations, etc.) of USS student employees should be standard and centralized.

• Each service desk should have a local manager that reports to a central service desk manager.

1.3.3 Training

• Cross-training within IT support teams, staff and students, should be provided to reduce single points of failure. Cross-training could be supported by developing a comprehensive training curriculum for all tier 1 and tier 2 staff supporting core and common services. Competency and proficiency should be evaluated after training.

• Dedicated trainer role(s) should be created that can deliver IT trainings (e.g. student employee training, training for new services, etc.) and/or assist with designing training curriculum that is delivered by other IT staff/subject matter experts.

• Ongoing professional development and trainings should be provided to IT staff.


10

2.0 Recommended Support Models A support model defines how a customer can get IT support, support expectations, and how the customer’s issue is handled from creation to resolution. Below is our general recommended support model for USS.

• More specific support model details for each of the focus groups can be found in their respective subsections below.

2.1 Service Desk Contact Points We recommend the service desk should have the following contact points during business hours*:

• In-person/walk-up • Phone • Ticket • Chat/remote support with user approval

We recommend the service desk should have the following contact points during extended hours*:

• Phone • Ticket • Chat/remote support with user approval

*For recommended business and extended hours, see the “ 3.0 Recommended Hours and Online Support” section below. 2.2 Support Tiers With an eye toward consistent support and creating a simple model, the support workflow and table below is the recommended level of support provided for each category of services (i.e. core, common, and unique).


11

Service Desk Specialized IT Professionals

Enterprise Developers/Service Owners

Tier 1 Tier 2 Tier 3 Core Services

• Intake and triage request • Identify the status and

availability of services • Perform basic

troubleshooting (e.g. access validation, connectivity, browser, etc.)

• Knowledge and access to do basic installation, configuration, or restoration

• Can solve most basic and common issues from start to finish without needing to escalate

• Can provide basic training and consultation for existing services

• Authors self-help documentations for customers

• Limited administrative rights

• Handles escalations from tier 1

• Triages requests for higher escalation

• May receive incident escalations from tier 1

• Performs advanced troubleshooting

• Handles complex issues

• Can provide advanced training and consultation

• Authors internal documentation for tier 1 to help reduce escalations

• Access to grant and change permissions

• Administrative rights to systems in order to perform administration tasks (e.g. advanced configuration, restoration, etc.)

• Handles escalations from tier 2

• May receive incident escalations from tier 1

• Authors internal documentation for tier 2 to help reduce escalations

• Full administrative and system level rights

• Can make change to global policies and settings

Common Services

• Intake and triage request • Perform basic

troubleshooting (e.g. access, connectivity, browser, etc.)

• Can work on a problem up until a certain point and then would need to escalate to tier 2


12

Service Desk Specialized IT Professionals

Enterprise Developers/Service Owners

Tier 0 Tier 1 Tier 2 Unique Services

• Unless otherwise defined in the service support plan, the service desk may not receive requests for unique services. If they do, they will intake and escalate/route the request

• Contact points should be known and documented

• If IT professionals serves as contact point, they'll provide tier 1 support.

• For unique services that are hosted on enterprise infrastructure (e.g. VM, storage, backup, etc.), may serve as a contact point for tier 2

As each tier level was discussed and defined, the following competencies were identified for staff in each support tier:

• Service Desk o Commonly filled by student employees and an ITC1 staff classification o Generalists good at resolving most technical support issues o Strong communication and customer service skills

• Specialized IT Professionals o ITC2 staff classification and above (i.e. senior support technicians and not

student employees) o Broader, deeper technical knowledge of systems/environment o Excellent troubleshooting, communication, and customer service skills o Good collaboration with tier 3

• Enterprise Developers/Service Owners o OSNA or OA staff classifications o Resides outside of the USS domain o Specialized or service specific knowledge o Technical or application experts/administrators in domain area

In order for this support model to be successful, we recommend the following tools and resources be required:

• Comprehensive and consistent training for the service desk. • Provide read-only access to basic account information through the identity management

system to all staff that perform tier 1 account support (See Appendix G - Read-only Identity Management System Access Proposal).

• Robust service documentation. • For services supported by USS, comprehensive support plans that include clear

escalation paths. • All IT staff using a central ticketing system (e.g. the UO Service Portal). • An up-to-date service catalog with contact points for all service categories (i.e. core,

common, and unique).


13

2.3 Service Level Expectations We recommend the model below be used as a starting place for service level expectations (SLEs). Additionally, we recommend the USS implementation team determine first touch and resolution times (in hours) once the exact number of USS staff are known.

• For first touch and resolution definitions, see Appendix C - Glossary for definitions.

Standard Urgent Critical Support Hours

Tier 1 (simple request)

First Touch: Resolution:



20 x 7

Tier 2 (moderate request)




M-F, 8am-5pm

Tier 3 (complex request)




3.0 Recommended Hours and Online Support 3.1 Business Hours We recommend that service desk business hours be consistent across physical locations and align with class hours. Business hours for service desks should be determined by the USS implementation team once we know the exact locations of the physical service desks and building hours. 3.2 Extended Hours and Online Support Plans for increasing support to 20 by 7 for the Information Services Technology Service Desk are already underway in order to support the existing and upcoming online education programs. Since this support model is already in motion, our recommendation is to continue moving forward with this support model for USS and that at least one service desk have extended walk-up hours. We recommend that extended hours be re-evaluated in the future once we better understand the need and volume for extended support.

PRIORITY LEVEL

TIER

S


14

3.3 Hours Between Terms Since the faculty and student population on campus is drastically reduced in between terms, we recommend support hours and student staffing be reduced during breaks. 4.0 Recommended Geographical Locations 4.1 Physical Locations We recommend at least five physical service desk locations for the Eugene campus and one service desk that is located in Portland that offers in-person/walk-up support. Service desk locations should be in high traffic areas and should offer broad coverage across campus. Our recommended physical service desk locations for the Eugene campus are the following:

• Knight Library • EMU • Lillis • A location east of Agate to support students in the dorms • A location north of Franklin since this part of campus will be quickly growing as the

Knight Campus comes online

In order to be able to provide effective IT support for campus, the physical service desks should be located in the places that people already are on campus and not places that they need to seek out. Service desk locations should be added to the campus map as well as the UO mobile app.


15

Prior to implementation of walk-up service desk locations, we recommend that the locations be further evaluated to better understand the need and volume for walk-up support. 4.2 Call Center We recommend implementing a central call center with dedicated manager(s) and sufficient staff to answer all IT service requests phone calls. Given all support options currently offered by the Information Services Technology Service Desk (excluding chat), a vast majority of support is provided via phone and ticket. Depending on space availability, this call center could be co-located with a service desk or independently located. We recommend that the same training level and skill required for service desk staff be required for call center staff. Student employees assigned to the call center should be rotated through the service desks to provide cross-training. Call center staff, along with service desk staff, would also be responsible for responding to service request tickets. 4.3 Off-Campus Support In the future, unstaffed remote kiosks for IT support at off-campus (e.g. OIMB, Spencer View Apartments, etc.) locations should be considered to ensure faculty, students, and staff not located on the Eugene campus can more easily and readily access IT support resources. The remote kiosks could have a screen, or a laptop, located at an off-campus location where someone could walk up, press a button, and have a USS technician available for video chat to help them. By using a remote kiosk for IT support, users can receive remote support from a technician without having to wait for a technician to come to them or having to travel to campus. 5.0 Focus Group Specific Recommendations The following focus groups proposed specific recommendations for each of their areas that are not included in the recommendations above. 5.1 Accounts & Access

• A credentialing agent(s) should be located at all service desks to assist with password resets.

• Easier remote password recovery should be facilitated either by expanding the number of credentialing agents and expanding their authority to all OUs, or by developing a more streamlined remote authentication process supported by centralized credentialing agents.

• The “UO Code of Responsibility” (see Appendix F – UO Code of Responsibility for Security and Confidentiality of Records and Files) should be integrated into the HR onboarding process at initial hire to allow more timely access to resources needed to begin work.


16

• Office staff should have the ability to request all access needed for a new employee in one request for core and common services.

• Affiliation resource access rules should be simplified to provide consistent and predictable services.

• A list of services using centralized authentication with contact points should be documented.

• Two-Step Login (DUO) should be implemented for all of campus and the requirement to update passwords periodically should be eliminated or, at least, password change requirements should be evaluated for adherence to best practice.

• Once Two-Step Login is implemented, the number of general campus credentials should be reduced to one and the separate DuckWeb login should be eliminated.

5.2 Knowledge Management 5.2.1 Tools

• We recommend the use of Confluence as a central repository for internal KBs given its present level of adoption and recommend consolidating Confluence instances on campus for cost savings.

• The current investment in the UO Service Portal, powered by TeamDynamix, makes it an efficient choice for centralized, externally-facing documentation for a knowledge (KB) accessible to all University-affiliated people. We recommend continuing adoption of the UO Service Portal, creation of a KB style guide that follows the UO style guide, and centrally-managed KB standards to ensure that KB articles are up-to-date and regularly reviewed for accuracy.

5.2.2 Staff

• We recommend that a knowledge manager role be created and filled by existing IT staff. The knowledge manager position should have previous knowledge management experience and be KCS certified or be expected to become certified in the future. This position is central to managing the KCS framework, promoting a knowledge-sharing culture, raising awareness, and engaging all levels of support staff and support leadership.

• The knowledge manager should work in collaboration and closely with the service desk.

5.3 Lab Management 5.3.1 Client Management (Mac and Windows)

• We recommend that all clients be managed with a shared framework which will support, at a minimum, a standardized method for distribution of applications, operating systems, computer customizations, and security updates. The recommended client management tools are Microsoft SCCM for Windows and Jamf Pro for Mac.


17

• We recommend the following support for client management: Student

employees/staff Staff

Staff

Tier 1 Tier 2 Tier 3 Responsibilities • Open/close labs

• Troubleshoot basic issues

• Install applications

• Handle warranty repair scheduling

• Set up new lab machines

• In consultation with tier 2, replace hardware as needed

• Removing and properly disposing of end of life hardware

• Handle escalations from tier 1

• Ensure proper access control, security cameras, etc.

• Create and test packages

• Ensure proper deployment of packages

• Workstation customizations

• Security management

• Create and maintain OS deployment methods

• Provide consultation

• Advanced hardware troubleshooting

• Handle escalations from tier

• Maintain management server

• Security patching • Framework/application

upgrades • Handle vendor

communications for hardware quotes, purchasing, etc.

• Handling lab reservations and scheduling

5.3.2 Hardware and software purchasing in coordination with EDM

• We recommend a single PC vendor (where possible) that has been integrated into DuckDepot for ease of purchasing and contracting. Additionally, we recommend purchasing Apple hardware directly through DuckDepot from Apple to allow leveraging of DEP.

• Hardware specifications should be appropriate to the lab where the hardware will be located.

• Hardware should have a reasonable replacement lifecycle in order to keep the lab machines from being outdated.

• Software that is purchased and installed in labs should be documented and managed by tier 2 support staff in order to reduce duplication of software and cost of licensing.


18

5.3.3 Hardware management in coordination with EDM • New hardware for labs should follow the standards and processes practiced by EDM. • Older hardware should be repurposed to new users or spaces, placed on surplus, or

submitted to E-Waste. • A fleet of backup machines that can be pushed out to locations as needed for repair or

replacement should be maintained. 5.3.4 Printing

• All labs should be able to print to a printer. This does not dictate that a physical printer be present in all labs, but that a printer can be accessed by all lab computers.

• Printing from labs should be on a centrally managed pay-to-print system (e.g. Pharos, Papercut, or WEPA).

• Prices should be set campus wide. Provisions should be made to allow for “free” printing so that departments can pay to provide their students free printing. Money from lab printing should be rolled back into fund supplies and service for printers.

• Payment for printing should not be cash based. DuckBucks should be the system used. • Supplies and printer servicing should be handled by CTX or whomever maintains the

central campus printing contract. EDM should not be relied upon to provide paper, toner, etc. for printers. Installing paper and/or toner in printers can be handled by lab student employees.

• Due to the support burden, steps should always be taken to reduce the printing load from labs and around campus. Printers should be configured to print double sided by default and faculty should be encouraged to have students submit work digitally.

• Access to printers from personal devices should be made available where appropriate and supportable.

• Specialty printing (wide format, special materials, etc.) should be made available as appropriate. Pricing should likewise be standardized.

5.3.5 Scheduling

• In order to reduce scheduling conflicts, lab reservations should go through one, central online request form for all labs.

6.0 Other Recommendations The following additional recommendations should be evaluated and potentially implemented in future phases of Transform IT or as part of USS, as appropriate. These recommendations could have an impact on USS support.

• A future Transform IT project should work closely with the UO Libraries to establish how educational technology, classroom technology support, and video conference support will be supported in conjunction with USS.

• Event support should be considered for a future Transform IT project and how events are supported in conjunction with USS.


19

• Campus wide standards should be developed for patching requirements and virus/malware hygiene for BYOD devices. A standardized process should be created for detecting and disabling non-compliant devices. This process should balance security and customer experience.

• A robust onboarding process for faculty/staff should be developed. Process may include: o Onboarding checklists o One entry point for new faculty/staff access o Adjusting business application/institutional data access rules to allow granting of

access a small window prior to employee start date o Mandatory security awareness training

• A robust offboarding process should be developed. Process may include: o Integrated and automated account closures for resources beyond those

managed by our central identity management system o Equipment recovery and re-use plan o Regular and consistent job terminations for temporary and student employees

• Awareness of processes that rely on accurate job data should be improved with our departmental payroll and HR partners. This would be required for timely onboarding and securing systems at offboarding.

• Equipment checkout (e.g. laptops, tablets, peripherals, etc.) should be provided to faculty, students, and staff in a coordinated and efficient manner between departments and the EDM team. In the minimum, hardware used for equipment checkout should be managed by the EDM team and walkup service desks should have adapters, cables, etc. for urgent classroom needs available for checkout. We recommend the USS implementation team determine how to best coordinate equipment checkout with the departments in regards to where hardware is located for checkout, which central system to use, processes, etc.

• Classroom hookups and connectivity for publicly shared rooms should be standardized. • A plan to phase out paper scanning services should be developed. This service should be

replaced with existing functionality present in Canvas. • The following data should be added to Active Directory to assist with automation: IT job

classification codes, faculty rank, and office locations (building and room number). • Digital/mobile wallets should be evaluated and determined if they would be an effective

replacement for physical ID cards.

Next Steps • Review recommendations with Jessie Minton, vice provost for information services and

chief information officer. o Mid-April 2019

• Present recommendations to Transform IT Steering Committee and IT Steering Committee.

o End of April 2019 • Begin implementation for User Support Services recommendations

o May 2019


20

Appendices Appendix A - Links to Data Gathered from Step 1

• Account and Access • Knowledge Management • Lab Management

Appendix B - Step 1 Stakeholders In step 1, additional data was gathered from the stakeholders listed below.

Department Name Advancement Michael DeTIe Athletics Virginia Register Biology Chung-Fei Tsai Business Affair Office Mark McCulloch Business Affair Office Michael Walsh CASIT Chad Little CASIT Ben Brinkley CASIT Mike Moresi Center on Teaching and Learning Peter Hoogenboom College of Design Sean Sharp College of Design Jeremy Smith College of Design Jason Shirley College of Design, School of Journalism and Communication

Gary Sullivan

College of Education Jeff Woodbury Computer and Information Science Lauradel Collins Continuing and Professional Education Skipper McFarlane Data Services, UO Libraries Jonathan Cain Division of Student Life Cleven Mmari Division of Student Life Michelle Brown English John Burridge Finance & Administration Dave Roberts Finance & Administration Shared Services Bill Anderson Finance & Administration Shared Services David Jordan Geography Lisa Knox Information Services Martin Abair

https://uoregon-my.sharepoint.com/:x:/g/personal/kdavis2_uoregon_edu/EYgWkMN30dRCm2nLpUD8TggB4rAo5B4juH3ZZUHzYETm0g?e=jKSGmK

https://uoregon-my.sharepoint.com/:x:/g/personal/kdavis2_uoregon_edu/ESjp6RKoADVOo9l7jg0xFyEBqYdP7yJm7NNwS94ewqZCIA?e=mG0DYs

https://uoregon-my.sharepoint.com/:x:/g/personal/kdavis2_uoregon_edu/ETpJtBfs-NxNmgjobE33L6UBn2MUtu0eE_4LG6tLTc7dkQ?e=FhXWOh


21

Information Services Patrick Chinn Information Services Sara Stubbs Information Services Andy Vaughn Information Services Jillian Sallaway Law School Dennis Bishop Lundquist College of Business Michael Suskin Lundquist College of Business Shandon Bates Museum of Natural and Cultural History John Ivie Prevention Science Institute Webb Sussman Printing and Mailing Services Bobbi Bengtson Psychology Will Seltzer Psychology Bill Troyer Research Technology Services Charles Powell School of Journalism and Communication Ryan Stasel School of Music and Dance Guy Eckelberger Services for Student Athletes Brian lee Student Services and Enrollment Management

Chris LeBlanc

Undergraduate Education and Student Success (Formerly "Undergraduate Studies")

Benjamin Starlin

University Health Center Charles Hollands University Health Center Alan Baker University Health Center Jerry Reese University Housing Douglas Hethmon UO Libraries Duncan Barth UO Libraries Michael Brown UO Libraries Al Cornish Vice Provost Office Portland Clayton O'Brien Vice Provost Office Portland Douglas Burzell Yamada Language Center Jeff Magoto ZFIN within ION Anne Eagle ZIRC Alex Schumann


22

Appendix C - Glossary Term Definition Examples

User Support Services Focus Areas Service Desk A service desk is the single point of contact

between an IT service provider and end-users. A service desk manages service requests, escalates or triages services requests, and handles communications with end-users. Service desk includes tasks that were previously handled by help desks and desktop support.

If an end-user has an IT-related question or problem, they contact the service desk for assistance. The service desk will assist the end-user or, if needed, escalate the issue while maintaining communication with the end-user.

Lab Management The management of computer labs used by students, staff, and faculty. Management of a computer lab includes: purchasing hardware/asset management, imaging, client access management, support, printing, space management (e.g. access, security, room design/layout), etc. Labs may also contain various classroom technology or assets that also require support. There are two types of computer labs:

1. General open-use labs: These labs are open all end-users for basic use and printing.

2. Specialized departmental labs: These labs are used by end-users in the respective department and the computers have specialized software and/or hardware installed.

Labs may be used a classroom space by faculty and students or scheduled for a variety of other uses (e.g. training).

If a student needs to work on a document in Word and print the document, they may choose to an open-use lab. If a School of Journalism and Communication (SOJC) student needs to use specialized software only available on a Mac, they may choose to use one of the SOJC labs.

Knowledge Management

A process used to gather, store, and share knowledge and information. The primary purpose of this process is to improve efficiency by reducing the need to rediscover knowledge.

Internal KB: If an IT staff person needs to know how to image a new computer, they would consult an internal KBA.


23

Knowledge and information is created in the form of knowledge base articles (KBA) and stored in a knowledge base (KB). There are two types of KBs:

1. Internal IT KB: This KB is strictly used by IT staff as a way to document how-to information for internal processes. This information is not shared with the general public, may contain sensitive information, and requires authentication.

2. External IT KB: This KB is used by all end-users and contains how-to guides, troubleshooting information, and answers to common questions. The goal of an external IT KB is for an end-user to be able to self-help themselves with an issue or question without needing to submit a help ticket. An external KB is public, however, some articles may require authentication.

External KB: If an end-user needs help configuring their email in Outlook, they would follow instructions found on an external KB.

Accounts and Access

Support for authentication, access, role-based provisioning, and other account and access-related activities for services.

DuckID account support (e.g. claiming, passwords, troubleshooting, manual assignments, etc.), business application access, identity management support, etc.

Service Levels Core Core services maximize efficiency, are

predictable IT services, and reduce the cost of IT to the business. Core services are campus-wide (i.e. offered to all UO affiliated users) and non-duplicative in nature.

Wired networking, DuckID, Email, Canvas, basic help with IT issues

Common Common services increase agility and allow for the development of new methods and tools that accelerate IT capabilities. Common services may be prevalently done or often.

Adobe products, CRM, Kronos, JIRA, for-fee services


24

Common services may be duplicative with a cause.

Unique Unique services allow for the freedom to innovate and support techniques to explore, adapt, and adopt new opportunities. Unique services are usually used by a single department and are non-duplicative in nature.

High Performance Computing (HPC), MRI machine, Piano Lab

Service Level Expectations Service Level Expectations

Service level expectations define the first touch and resolutions times that a customer should expect to receive upon making a request.

Operational Level Expectations

Operational level expectations define the response and resolution times between IT teams.

First Touch First touch begins when a technician provides an initial response and begins actively working on the request. Calculation: Time from creation to initial reply/start of work/change of status out of "New".

Resolution Resolution time calculated as the total time a technician is working on a ticket minus the time spent waiting for a customer and/or escalated resource. Calculation: Time from creation to resolution minus time waiting for customer response to inquiries.

Standard An easy solution can be provided and the request does not disrupt service.

Urgent User’s work may be impacted soon. Critical Immediate attention is required.

Appendix D - Core, Common, and Unique Services The service desk and accounts and access focus groups categorized IT into core, common, and unique buckets. Notes about the service categorizations below:

• Service names and structure mostly follow the service catalog structure in the UO Service Portal.

• Some services may appear in multiple buckets (i.e. core, common, or unique) due to the different offerings (i.e. tools/applications) of a service that may be supported at different support tiers.

• The table below is not a complete list of all IT services. Additional detail on service offerings identified as core, common, and unique can be found in the individual focus groups reports. See Appendix H – Focus Group Reports.


25

• We recommend this list be reviewed and expanded upon in more detail during USS implementation.

Service Category

Core Common Unique

Collaboration • Email & Calendaring

• File Sharing • Telephones &

Voicemail • Video

Conferencing Software

• Websites

• Departmental Intranets

• Email • File Sharing • Four Winds

Digital Signage • Instant

Messaging • SharePoint • Telephone &

Voicemail • Two-Way Radio • Video

Conferencing Hardware

• Video Conferencing Software (e.g. WebEx, Zoom)

• Websites • Wrike

• Cable Television

End-Point Computing

• Equipment checkout

• Personal/Student Desktops & Devices

• Printing & Copying

• Software & Applications

• Networking

• Asset Management (e.g. inventory.uoregon.edu)

• Client Management (e.g. Jamf)

• Departmental Software

• Office/Department Desktops & Devices

• Printing

• Departmental Software (e.g. Fusion, Maxient, CS Gold, etc.)

• Mobile Wireless Devices (MiFis)

• Departmental VPN (e.g. Health Clinic VPN)

IT Professional Services

• Authentication Services

• Systems Administration

• Departmental Systems Administration


26

• Data Backup • Training • IT Consulting • UO Service

Portal • Shell

• Virtual & Physical Servers

• Data Protection • Bomgar • RT Ticket Service • IT Consulting

• Departmental Data Protection

• Departmental Software & Application Development

• Departmental IT Consulting

• Network Management Security • Accounts &

Access • Information

Security

• Accounts & Access

• Information Security

Teaching & Learning

• Classrooms & Labs

• Teaching & Learning Systems

• Classrooms & Labs (e.g. VDI, Panopto)

• Teaching & Learning Systems

• Educational Technology Consulting

• Scantron Services • Event Support

• Classrooms & Labs (e.g. DeArmond MakerSpace)

• Teaching & Learning Systems (e.g. Video production & streaming)

Administrative & Business

• Business Applications (e.g. Banner, DuckDocs, CRMs, etc.)

Other Unique services used by departments to meet their business needs: • AiM • AMAG • Calcium • CardioPerfect Spirometer • Caterease • Compass • Conference Programmer • Converge • direct EDGAR • EagleSoft Dental Software • eAPM • Eatec • EHS Assist • E-PCS


27

• Equitrac • Ex Libris Alma • Facility ticket system • FOIAXpress • Icinga • Insight • Medicat Medical Records • Medstart Joints Xray PACS • Micros • Milestone • Mimsy XG • mPulse • PERS EDX • Practice Partner Medical

Records • ProPharm Pharmacy

Software • SFax Secure Fax • Singlepoint • Sunapsis • Symmetry • UOPD LEO Systems • WebCRD • Webcheckout •

Appendix E - Data Used for Geographical Locations The following data was utilized by the Accounts and Access focus group for step 5. Technology Service Desk support types (Last 12 months)

Source Ticket Count

Percent

Phone 5929 43% Web 3752 27% In Person 3349 24% Internal 374 3% Email 163 1% Unidentified 88 1% API 53 0% Chat 3 0%


28

Population Served for In-person support (TSD, Last 12 months) Ticket Count

Primary Affiliation Percent

2271 Student/Alumni 68% 924 Faculty/Staff/Other 28% 124 Unidentified 5%

Support Offered by Campus IT Units

Contact Method Offered

Percent of Faculty/Staff Receiving this Support

Phone 100% Remote 88% Desk Side 71% Central/Walk-Up 29%

Appendix F – UO Code of Responsibility for Security and Confidentiality of Records and Files User’s requesting access to business applications is required to sign the UO Code of Responsibility complying with the following: Security and confidentiality are matters of concern to all University employees and to all other persons who have access to administrative records, education records, reports, or any other confidential or privileged documents or information. The purpose of this code is to clarify responsibilities in these areas. Each individual who has access to confidential or privileged information is expected to adhere to the regulations stated below: Any person who has access to administrative records, education records, reports, or any other confidential or privileged documents or information, may not:

• Reveal the content of any record or report to anyone, except in the proper conduct of his or her work assignments and in accordance with University policies and procedures.

• Make or allow any unauthorized use of information. • Include false, inaccurate or misleading entry in any report or record. • Expunge a data record or a data entry from any record, report or file. • Share individual passwords with any other person. • Seek personal benefit or allow others to personally benefit from the knowledge of any

confidential or privileged documents or information. • Remove any original or copy of an administrative record, education record, report, or

any other confidential or privileged document, from the office where it is maintained, except in the performance of official duties and authorized by law.

Any knowledge of a violation of this code must be reported immediately to the violator’s supervisor. Violations may lead to disciplinary action, including dismissal. Violations may also lead to criminal and civil liability.


29

Appendix G - Read-only Identity Management System Access Proposal Purpose: To empower distributed support technicians to more quickly and accurately do Tier 1 DuckID account support. Requirements:

• Employed by UO • Approved by Department Head • Agree to UO Code of Responsibility • Job duties include direct support for DuckID account issues • Complete training on handling FERPA flags, interpreting information in Trident, and how

to escalate questions.

Scope: Read-only access to certain fields for all accounts. Fields would include the following:

• DuckID • UO ID • Email Address • Calculated Display Name (*This would be a new field in Trident* - same as display

name for LDAP/AD) • Responsible Party Name • Responsible Party UOID • Account Status • Claimed • Password Exp Date • Password Change Date • Password Status • Reserved Username • Email Forward • Secondary Status • Confidential Flag • Actual ADOU • Home Department • Department 1 • Job Title 1 • Department 2 • Job Title 2 • List of active groups • List of active roles

Any upcoming data showing location of mailbox (webmail/Exchange/Exchange Online).


30

Appendix H – Focus Group Reports Links to the full focus group reports.

• Accounts & Access • Knowledge Management • Lab Management • Service Desk

Appendix I – Implementation Considerations The considerations below should be used by the USS implementation team. Dedicated Trainer(s) The dedicated trainer(s) role should be able to assist with the following:

• Student employee turnover by helping provide consistent and highly available training • Basic ITIL training and resources to all IT staff • Campus user training for new service offerings • Coordinate with subject matter experts for specialized training • Help design curriculum that can be delivered by others • Provide mandatory training for IT staff on FERPA, and specialized training for HIPPA and

PCI compliance for those dealing with that data IT Zone Support

• Determine the specific zone boundaries and staffing in the zones that meets or exceeds best practices for ratios of support staff to end-users or devices.

• Support staff should be close in physical proximity to allow for rapid response times when needed.

• Zones should specialize around customer types to allow for higher skill development of support staff (e.g. science specialty, administrative specialty, general academic support, etc.).

• Support zones may overlap physically or exist in close proximity in some cases. • There should be dedicated zone for remote campus locations in Eugene (e.g. 942 Olive,

Baker Downtown Center, Peace Health, etc.). The physical location of this zone would be on or off campus, but would require adequate transportation for traveling to different remote campus locations.

• Support staff in zones should have a common reporting and training structure to maintain consistent and uniform services to all faculty and staff.

• We should take advantage of existing departmental IT staff and office locations for distribution where possible.

• Zone rotations should be considered as a way to cross-train IT zone staff. Service Level Expectations

• Framework should be evaluated thoroughly prior to implementation. • Determine first touch and resolution times (in hours).

https://uoregon-my.sharepoint.com/:b:/g/personal/kdavis2_uoregon_edu/EWt3-0IArz1CrnGCjqO8MWUBk_hOAeWLgaTmKvDb1z3Duw?e=Qs56de

https://uoregon-my.sharepoint.com/:b:/g/personal/kdavis2_uoregon_edu/EWxBal1BJX1BmJfrTB3VS7cBbnJUr44PsQ6VD2Xlgq59bA?e=nnlxot

https://uoregon-my.sharepoint.com/:b:/g/personal/kdavis2_uoregon_edu/EdqN-UDacEtKkVtATu90xuQBhxt9aoupzmRC8dITYp2Bkw?e=FRAWDl

https://uoregon-my.sharepoint.com/:b:/g/personal/kdavis2_uoregon_edu/Ec8UrTW3uUBMqzA1q3eHGu0Bcl_ni3Tx4RNBCLugZ1kwUQ?e=kazkhy


31

• Time sensitive services that may disrupt learning or business may need different first touch and/or resolution times. These should be evaluated individually during implementation.

• An owner should be assigned and should be responsible for measuring and managing SLEs.

• In order for first touch and resolution times to be achieved, operational level expectations (OLEs) should be established. OLEs should have targets that underpin those with an SLE to ensure that targets will not be breached by failure of the supporting activity.

• Challenges that will need to be worked through during implementation: o Tier 1 and tier 2/3 have different business hours. o To ensure SLE times can be met, adequate staffing will need to be considered.

Service Desk Business Hours

• Determine business hours for service desks once we know the exact locations of the physical service desks and building hours.

Service Desk Extended Hours

• Consider physical security for USS student employees and supervisory FTE during implementation.

Geographical Locations

• We recommend the USS implementation team visit and evaluate each recommended service desk location to evaluate space requirements, availability, etc.

Lab Management

• Who pays for labs (e.g. the department where the lab is located or labs are paid for centrally)?

o If a department pays for a lab, then can other units use them? o If labs are paid for centrally, how do departments that rely on them maintain

control? • Labs should be interchangeable. For example, if a pipe breaks and a lab is flooded, a

class should be able to be moved to an alternate space with little warning. Specialized labs would be excluded from this.

Equipment Checkout

• Determine how to best coordinate equipment checkout with the departments in regards to where hardware is located for checkout, which central system to use, processes, etc.

user support services recommendation · 2019-05-09 · 4.2 call center ... manager information...

Documents