eProtocol Service Level Expectations
University of Minnesota
SIRC eProtocol Service Level Expectations (SLE)
eProtocol Support Committee
10/19/2012
eProtocol Service Level Expectations
Table of Contents
1
eProtocol Service Level Expectations
Introduction
This Service Level Expectations (SLE) document covers services provided by eProtocol Support. The SLE defines the commitment and responsibilities of all parties involved to ensure these services are delivered in an effective and professional manner. eProtocol Support partners with SIRC Business Units, OIT and the vendor to establish and maintain this agreement.
The SLE includes:
Detailed information on support services
Expectations of end-users
Expectations of SLE Partners
Expectations of the eProtocol Help Line at each Support Tier
Performance tracking mechanisms to monitor and improve service
Procedures to review and modify the agreement
End Users:
eProtocol End Users are faculty, students, staff and other individuals working with eProtocol. eProtocol End
Users are covered under this SLE when performing their work using eProtocol. SLE End Users are responsible for:
Contacting the helpline(s) via the designated e-mail or voicemail means
Submitting requests to the helpline with as much lead time as possible
Providing necessary information to helpline staff
Following University technology guidelines, standards, and policies
eProtocol Help Line Staff
eProtocol Help Line Staff provide support at various tiers. Tier 1 is the business unit. Tier 2 is the OVPR IT. Tier 2 coordinates with Tier 3A (OIT) or Tier 3B (Vendor) as appropriate to resolve an issue.
Tier 1 and Tier 2 Help Line Staff are responsible for:
Defining and managing service expectations through SLE
Providing support services as defined in this Service Level Expectations document
Maintaining appropriately trained staff
Communicating eProtocol Support Committee responsibilities unit staff and end users as appropriate
Following the review procedures to address SLE changes
Reviewing, approving, and supporting all aspects of the SLE
In addition, Tier 2 Help Line Staff are responsible for:
Monitoring and tracking all requests, tasks, and projects
Validating solutions or fixes with customers before closing requests
Submitting reports and updates to SLE Partners at regular meetings
2
eProtocol Service Level Expectations
SLE Partners
SLE Partners include eProtocol Support Committee members as well as the eProtocol Help Line staff at each support tier. eProtocol Support Committee members eProtocol Support Committee members are individuals from each Unit, who serve as the primary contacts for discussions and decisions related to this SLE. They act as site administrators, business decision makers, system administrators, and OIT and/or Vendor representatives. Partners are identified in the SLE Partners List in
Appendix A. eProtocol Support Committee Members are responsible for:
Communicating business needs to the eProtocol Support Committee
Communicating expectations and responsibilities of the eProtocol Support Committee and business unit to staff and subsequently, end users
Reviewing support performance with eProtocol Support Committee
Following the procedures to make modifications to the SLE
Supporting the Service Level Expectations
SLE Customers:
Customers are U leaders/executives who have budget/decision making authority.
3
eProtocol Service Level Expectations
Support Strategy Overview
The implementation of the eProtocol system represents a significant change in technology approach from the existing custom developed and maintained compliance and tracking systems. Responsibility for configuration and administration of the system will be placed much more in the hands of the business knowledgeable OVPR staff.
A primary goal of the eProtocol project is to facilitate and manage research compliance from a researcher’s perspective.
The business units and project team invested extensive time and effort to create a consistent look and feel to the various eProtocol modules in order to provide researchers with a harmonized and dependable experience throughout the application. The support expectations outlined in this SLE reflect this goal, endorsing measures that ensure that eProtocol’s PI-centric focus, consistent look, feel, and language across modules, as well as a collaborative vision and management plan that will continue into the future. The SLE outlines a governance structure and support model that will appropriately addresses the business and technology, but also includes recommendations around documenting and understanding the experience of internal and external to help deliver continuously improving service.
The SLE will be available to all users of the system.
Business System/Customer Support Framework:
The eProtocol Support entity is structured as follows:
4
eProtocol Service Level Expectations
5
eProtocol Service Level Expectations
Governance: With respect to eProtocol product support, the term “Governance” describes the overall approach through which the business directs and controls the product support implementation, using a combination of shared information and hierarchical control structures. Governance activities ensure that critical information is documented and sufficiently complete, accurate and timely to enable appropriate decision making. It provides the control mechanisms to ensure that strategies, directions, and instructions are documented and carried out systematically and effectively.
Sponsors: Sponsors for this project include OVPR Vice President and the University VP/CIO. Sponsors are responsible for reviewing, approving, and funding recommendations made by the eProtocol Steering Committee.
eProtocol Steering Committee: The eProtocol Steering Committee will be comprised of eProtocol Business Process Owners,
OVPR IT representatives, the OIT Service Owner and when appropriate, the vendor. The Steering Committee will be charged with reviewing, approving, and funding recommendations made by the Support Committee.
eProtocol Support Committee: The eProtocol Support Committee is comprised of representatives from each business unit and
OVPR IT. Committee members will meet routinely (frequency TBD) to share and review each unit's list of documented change requests, issues, management metrics, etc. Group members will share pending changes to business policies and procedures.
They will coordinate change among appropriate roles and modules to keep processes, documentation and support information current, accurate, and maintain continuity across modules, as appropriate. The committee will discuss impacts, plan, and recommend priority changes to the Steering group. This group is essentially responsible for coordinating both the technical change management process and the non-technical change management process for all users of the system. The support committee ensures that all changes to the system, at all levels are planned for, happen in concert with appropriate support units, and are communicated to users in an appropriate way.
Business Units: Business units will serve as the initial point of contact for all eProtocol support requests relating to their respective module. Business units are responsible for usability support, for answering user questions that require unique knowledge from business unit staff, and for clarifying processes and form logic. Business units are responsible for escalating issues identified as system issues to OVPR IT. Business units are responsible for business continuity planning, i.e., if a system is unavailable, they must have a contingency plan that allow researchers to submit and/or manage their time-sensitive compliance information. They refer end-users to available training or hands-on orientation. Business unit staff will also participate in testing and validating system changes. Each Business unit has a “Site Administrator” role(s) which is capable of making local, minor changes that do not affect other modules or compromise form logic, pending Support Committee decisions. See “Appendix B: eProtocol Support Roles” for more detail.
OVPR IT: OVPR IT will serve as the liaison between business units, OIT, and vendor. The OVPR IT team tracks all issues escalated by business units from creation to resolution. They respond to and communicate about system outages and maintenance, analyze system malfunction and enhancement requests, document application enhancements and changes, assist with prioritization, and coordinate system-wide changes. The OVPR IT Team will also be responsible for system access and participate in testing and validating system changes. The OVPR IT Team has a “System Administrator” role(s) which is capable of making minor global (across multiple modules) changes, pending Support Committee decisions logic. See “Appendix B: eProtocol Support
Roles” for detail.
OIT: OIT is responsible for hosting, system monitoring, disaster preparedness and recovery, tracking all issues escalated by OVPR
IT from creation to resolution, Installing/applying vendor provided system updates, upgrades, and changes and testing and validating system changes.
Vendor: KSI is responsible for tracking all issues escalated by OVPR IT/OIT from creation to resolution. They will resolve system issues and provide fixes, Implement enhancements and provide code changes, and communicate about system updates and upgrades to OVPR IT.
6
eProtocol Service Level Expectations
Support Phases
To properly prepare for and support an enterprise transition of the SIRC project’s magnitude, the time surrounding system launch is divided into three phases:
I.
Go-Live Phase(s)
II.
Ongoing Support Phase
III.
Data Conversion Phase(s)
Phase I: Go Live Phase(s)
The Go Live phase is 4 weeks long and begins 1 week prior to launch. This phase is repeated with each addition of new functionality (new modules, major enhancements, data conversion, etc.). The 4 week timeframe considers the typical monthly support patterns but also prepares for intensity peaks due to industry deadlines, people’s work habits, etc.
Legacy data conversion is scheduled to be done 3-4 months after go-live of a given module, with the exception of UFRA, which will be converted prior to go-live.
Planned Go Live Phases
Planned
Release
#
1
2
3
Release Type eProtocol Functionality Included Target Date
Module Release IACUC module, CS Module, IBC Module November, 2012
Module Release IRB Module
Module Release UFRA Module and Post Approval
Monitoring functionality
TBD
TBD
Phase II: Ongoing Support Phase(s)
Following the Go Live phase, we transition into the Ongoing Support Phase. Ongoing support phase is all time outside of a Go Live period.
Phase III: Data Conversion Phase(s)
The eProtocol Data Conversion process and plan are currently being finalized. Legacy data conversion is scheduled to be done 3-4 months after go-live of a given module, with the exception of UFRA, which will be converted prior to go-live.
Data Conversion is being planned as a separate project with a distinct timeline in order to distinguish between typical
Go Live issues and potential data issues. Additional detail on the data conversion process need to be identified
(anticipated # records for conversion, conversion type, duration, etc.). Until then, the recommendation is treat each data conversion (DC1, DC2, and DC3, as referenced in “Release Schedule” above) as its own “Go Live” phase and staff accordingly, to address potential spikes in support needs.
Planned Data Conversion Phases
Planned
Release
#
DC1
Release Type
DC2
DC3 eProtocol Functionality Included
Data Conversion IACUC, CS, and IBC (targeted for 3-4 months after each module’s Go-Live)
Data Conversion Data Conversion for IRB (targeted for
3-4 months after Go-Live)
Data Conversion UFRA Data Conversion
Target Date
TBD
TBD
TBD
7
eProtocol Service Level Expectations
eProtocol Hours of Operation:
eProtocol is scheduled to be available Monday thru Saturday 24/7. The system is under maintenance Sunday from 6 a.m. to noon (corresponding to PeopleSoft maintenance schedule) and will be unavailable to users. The system will become available again on Sunday following the maintenance period.
eProtocol Help Line(s)
Each Business Unit operating eProtocol offers users a business-specific help line option, to ensure users get the right information quickly and easily.
Compliance Area
IACUC
IBC
Controlled Substances
IRB
REO
UFRA
SPA
1-HELP
Help Line #
612.626.2126
612.626.5654
612.625.9057
612.626.5654
TBD by Release III
TBD by Release III
612-624-0467
Call (612) 301-4357 (on campus, dial 1-
HELP)
Help Line email iacuc@umn.edu ibc@umn.edu ovprreo@umn.edu irb@umn.edu
TBD by Release III mtagree@umn.edu eProFund@umn.edu
Live Chat
(http://www.oit.umn.edu/help/)
Displaying eProtocol Help Line(s) Information
# Online Location Help Line # Displayed
1 Launch Page List of each units’ Help Line Number
2 Login Page
3 Research
Dashboard
4 Instructional
Text Within a
Compliance
Module’s Form
5 eProtocol “HELP”
Function
6 1-Help
List of each units’ Help Line Number
List of each units’ Help Line Number
Unit Help Line Number specific to compliance module
List of each units’ Help Line Number
1-HELP (1-4357)
Detail
Users who browse to the eProtocol launch page
(the “about” page on the OVPR website) are presented with an appropriate Help Line contact.
This provides individuals an option to learn more about the project’s scope and make general inquiries.
The page will display the Help Line information for the specific module that the researcher has entered, i.e., The IACUC Help Line will display within the IACUC form.
Users who access 1-Help will be guided to appropriate eProtocol Help Line.
8
eProtocol Service Level Expectations
Tier 1 eProtocol Help Line Operations
Help Line Hours: eProtocol Help Lines provides support services coverage Monday through Friday from 8:00 a.m. to 4:30 p.m., University holidays excluded. Outside of those hours technical service requests may be submitted and will be assessed by the technical staff beginning at 8:00 a.m. the next business day.
Issue Tracking and Escalation
Business unit staff will determine if and when support requests should be escalated to Tier II (OVPR-IT) support.
Upon receiving an escalated support request, Tier II will open a ticket, resolve the issue or work with the appropriate entity (OIT or Vendor) to resolve the issue, contact the end user with the resolution, test the resolution, and close the ticket. Escalation from tier 1 to tier 2 will be performed via approved online forms to consistently collect essential information. All support requests that OVPR IT receives will be tracked and resolution timeframes will be reportable.
Tier 2 (OVPR-IT) Help Line Operations
Support Requests: Severity Level Definitions
The eProtocol Help Line prioritizes support work by assigning severity levels to support requests. Severity levels are assigned based on impact on business. While requests with a higher severity level will usually have a higher priority level, severity and priority are distinct. The planned or unplanned nature of a request is an important factor in prioritizing work. Severity levels are defined as follow:
Severity Level Definition
Urgent
High
Normal
Urgent severity level requests refer to situations with immediate and major impact on the OVPR’s ability to conduct its work or on the University’s reputation. These are situations where the entire IT
Team may be involved, current work may be interrupted, and staff may be called upon to work beyond normal hours of coverage.
High severity level requests refer to situations with significant impact on end user or staff member’s ability to conduct time-sensitive work. Under certain circumstances, eProtocol Support may provide a temporary solution and assign the request a lower severity level until the request can be fully resolved.
Normal severity level requests refer to situations with limited impact on end user or staff member’s ability to conduct their work. The majority of requests will be assigned a normal severity level.
Low Low severity level requests refer to situations with no immediate impact on end user, OVPR business, or staff.
Examples
A technology system failure affecting many employees with no workaround available
System failure affecting many employees with no workaround
Technical problems resulting in an employee’s loss of access to important technology services
User account issues preventing employees to perform time sensitive work in the system
“Add User” requests
“Change role” requests
Questions about software compatibility
Modify text on a page
9
eProtocol Service Level Expectations
Support Notification Process
When an issue is escalated to Tier 2, OVPR IT provides customers with technical service request acknowledgements, updates, and resolutions by University e-mail or voicemail and direct communication as detailed below.
Severity Level
Urgent
High
Normal
Acknowledgment
Within 15 minutes from initial contact or report
Within 30 minutes from initial contact or report
Within one business day
Resolution Time*
Target: within two hours. If the problem cannot be resolved in the targeted timeframe, OVPR IT staff and/or external partners will work continuously until resolution or an acceptable solution is in place.
Target: within four hours. If the problem cannot be resolved in the targeted timeframe, OVPR IT staff will work continuously during normal business hours until the problem is resolved or an acceptable solution is in place.
Target: two business days. If the problem cannot be resolved in the targeted timeframe, OVPR IT staff will work as appropriate during normal business hours until the problem is resolved or an acceptable solution is in place.
Low Within two business days Target: two weeks. If the problem cannot be resolved in the targeted timeframe, OVPR IT staff will work as appropriate during normal business hours until the problem is resolved or an acceptable solution is in place.
10
eProtocol Service Level Expectations
Enhancement Requests eProtocol Support differentiates support requests from enhancement requests for the purposes of work planning and reporting. Whereas Support requests are assigned severity levels, enhancement requests assign effort estimates (number of hours needed to complete the work). Enhancement requests are then prioritized and scheduled based on the eProtocol Steering Committee recommendation, OVPR unit work plans, and impact on business, current IT workload and commitments. The following three project definitions are commonly used when prioritizing enhancement requests:
Enhancement Requests: Effort Estimates
Definition
Small
Estimated Effort
Hours
Less than 4 work hours
Examples
Add an additional section to the
Help Text
Targeted Delivery
Medium
Large
Less than 40 work hours
Greater than
40 work hrs.
Add a new section to a form
Add several new sections or functional elements to a form
Based on business prioritization, technology prioritizations processed by the Support Committee, approved by the eProtocol
Steering Committee and included within the work plan, and other internal and external dependencies
11
eProtocol Service Level Expectations
Measurement, Reporting, and Performance Targets
A.
Tier 1 Metrics
Each business unit will determine which business metrics (e.g., “Turn Around Time Report”) are relevant to monitor and manage. eProtocol management reports can be used to support this process.
B.
Tier 2 Metrics
OVPR IT will continue to monitor and track the same important support metrics listed in its Service Level
Expectations for all system related requests (namely volume, responsiveness, time to resolution, and customer satisfaction), extracting this information from OVPR IT’s request tracking system.
OVPR IT Support will monitor essential service level metrics and provide SLE Partners with reports to track and analyze performance as detailed below. Performance tracking identifies specific areas where the SLE is not being met and will help IT and SLE Partners work together to determine appropriate solutions.
Unit Services Metric eProtocol
Support
Committee
Customer
Support
Manage
Enhancements
Volume
Responsiveness
Resolution
Quality
Timely Delivery
Quality
Report Performance Target
Requests Submitted Not Applicable
Requests Resolved Not Applicable
Initial Response Time 90% within SLE
Resolution Time
Customer
Satisfaction
90% within SLE
95% met or exceeded expectations
Closed project report
90% of projects delivered on or before due date
Customer
Satisfaction
95% met or exceeded expectations
12
eProtocol Service Level Expectations
C.
Reviewing Metrics
The Support Committee is responsible for reviewing support-related metric reports for all units, prioritizing and coordinating change requests across units, and determining the appropriate course of action.
Agreement Period, Review, and Approval
eProtocol Support and SLE Partners will review the SLE 6 months after the launch of release I and annually thereafter. Reviews of any component of the SLE should be requested in writing by SLE Partners or the eProtocol
Support Committee. The process to modify the SLE is as follows:
1.
eProtocol Support Committee document the business need for service revisions
2.
eProtocol Support Committee assess the impact of requested revisions
3.
BPO’s and eProtocol Support Committee as appropriate, determine implementation approach and timeline
4.
eProtocol Support Committee coordinates training for staff as necessary
5.
eProtocol Support Committee and SLE Partners finalize SLE
Approved: 10/10/2012
Last review:
Next review:
13
