eServices Provisioning SC

Service

eServices Provisioning

Service Manager
Michael Gerholdt, Manager of Enterprise Reporting and Development
Department

Contact
103i Maytum Hall, 716 673-3388, Michael.Gerholdt@fredonia.edu
Service Owner
AVP/CIO - Stephen Rieks
Description
  • eServices provisioning begins with an Identity Management layer, parts of which are automated and parts of which are not. All persons who receive eServices must first have a record in the Banner database (Oracle). Since Banner is at heart a Student Information System, students are a natively identified constituency based on a variety of status indicators. Alumni are a subset of Student with a different set of eServices provided. State employees are imported into Banner programmatically, and indicators present in their records are used to identify them regarding creation of eServices. Other constituencies are employees of non-state campus agencies, guests and EC English. These individuals are put into Banner either individually or through load files.
  • eServices provisioning is in two parts. 1) The identity management part determines who is eligible for eServices; 2) the act of provisioning takes place by determining when those services should be provided. Each constituency has its own sets of rules that prompt the creation of eServices for members of that constituency.
Service Users

eServices provisioning is a basic service provided to all regular constituencies on campus as identified in the overview.

User Services

eServices may include the following: Active Directory membership, Google Apps membership (which includes email), network logon, WiFi logon, FredCard, Door Access. 

Business Services

There are a number of downstream services for whom eServices provisioning is a necessary prerequisite, and these services provide their own sets of services. For example, our LMS, Maintimizer, FSA’s myFredCard and many other applications depend on membership in AD for authentication. AD itself is a root service which is populated primarily by the eServices provisioning program in Oracle. FSA’s IDMS (Identity Management System) is the generator of FredCards and that is likewise primarily populated from eServices provisioning. ProWatch, the door access system, is populated from FSA’s IDMS when the eServices application inserts records to the FSA IDCard table.

Technical Services

There are a number of packages, procedures and tables that support eServices provisioning within Oracle itself. The heart of it, though not the whole of it, is in frd_Services package.

Requirements

Rates / Cost of Use

No fees

Getting Started

For guest or Campus Community (campus employees other than state employees) requests for eServices are made via FredQuest. For students and state employees, no special requests need to be made as they are provisioned programmatically based on status and timing.

Availability

Typically, requests for access are worked on during normal business hours. FredCards and door access can be available immediately after data entry into Banner. A daily process at noon creates load files for Active Directory.

Getting Help

How does a user request assistance for the service? Via FredQuest.


Who can ask for certain aspects of assistance?

  • Anyone using eServices and having difficulty may request assistance and review
  • Any sponsor of guests may do the same
  • Responsible persons in non-state campus agencies for their staff


The ITS Service Center handles all typical user issues with eServices. They should only pass on a ticket to the FredQuest eServices team (a cross-ITS team group consisting of persons from Enterprise Infrastructure Services and Enterprise Reporting and Development Services) when the issue is technical beyond their ability to analyze and address.


All requests for assistance are completed using FredQuest:
https://fredquest.fredonia.edu/

SLA Notes

Users should request access for guests or incoming employees 2 weeks prior to the time when they will be on campus and need to have services available.

Business Procedures

Change Procedures

Assigned Primary Support

Assigned Secondary Support

RACI Chart

Who is responsible, accountable, consulted and informed for each function of your service?


Function 1

Name: Identity Management

Description:

Level

Responsible

Accountable

Consulted

Informed

Primary

Service Manager

Service Manager

eServices Team

CIO

Secondary

Service Manager

Service Manager

eServices Team

CIO

Tertiary

Service Manager

CIO

eServices Team

Provost

Function 2

Name: Provisioning

Description:

Level

Responsible

Accountable

Consulted

Informed

Primary

Service Manager

Service Manager

eServices Team

CIO

Secondary

Service Manager

Service Manager

eServices Team

CIO

Tertiary

Service Manager

CIO

eServices Team

Provost

Function 3

Name: End User Support

Description:

Level

Responsible

Accountable

Consulted

Informed

Primary

Service Center

Service Center Manager

eServices Team

CIO

Secondary

eServices Team

eServices Team

eServices Team

CIO

Tertiary

eServices Team

CIO

eServices Team

Provost


Date Last Modified
Status
Active