Enterprise Applications

EAPP Glossary

Table of contents:

Steering Groups

EAPP & DLT participate in a variety of steering groups that include representatives from multiple departments. Each steering group works to prioritize and coordinate the support, development, maintenance, communication, and release engineering for supported services. help to prioritize and coordinate the support, development, communication, and release engineering for supported services. Each working group meets periodically with stakeholders to discuss emerging support needs and ongoing projects.

Electronic Signature Review Group (ESRG): 

Steering group for electronic signature systems, such as Adobe Sign.

Enterprise Training Collaborative (ETC):

Steering group for training management systems, such as CSU Learn and LinkedIn Learning.

Data Analysis Working Group (Dawgs):

Steering group for PeopleSoft systems, such as the PeopleSoft CS, HR, and CFS databases.

Learning Management System Advisory Group (LMS Advisory):

Steering group for learning technologies systems, such as Blackboard Learn, Kaltura, and Zoom.

TeamDynamix Steering Committee:

Steering group for IT service management systems, such as TeamDynamix.

TeamDynamix

TeamDynamix (TDX) is the university’s enterprise IT services management system, often referred to as a “ticketing system” for IT services.

TDX includes multiple interfaces, including the customer-facing TDClient and technician-facing TDNext.

TDX Ticket Metadata

A ticket is digital record of work. Different ticket forms may track specific fields, but some fields and terms are common across all ticket types.

Age:

Days since the ticket was created.

Account/Department:

The primary group associated with the requestor.

Classification:

A broad category identifying the type of work associated with the ticket. Typically either an incident, service request, or change. See “TDX Ticket Classifications”.

Created:

The date and time when the ticket was created.

Form:

The set of fields associated with the ticket. Typically assigned by default based on the service catalog entry that was used to submit the ticket.

ID:

A unique numeric identifier for each ticket.

Modified:

The date and time when the ticket was last edited or updated.

Primary Responsibility:

The person currently responsible for handling the ticket, or “Unassigned” if the ticket is assigned to a group.

Requestor:

The person who is requesting work or reporting an incident.

Responsible Group:

The group currently responsible for handling the ticket. Typically assigned by default based on the service catalog entry that was used to submit the ticket. This may change if the ticket is escalated or reassigned.

Priority:

Low, medium, high, or emergency.

Status:

Indicates progress on the ticket. See “TDX Ticket Statuses”.

Subject:

Title of the ticket, should be a brief and memorable summary of the request.

Task:

A small unit of work within a ticket, which itself can be assigned to a group or person.

Task Template:

A standardized set of tasks that can be added to a ticket.

Workflow:

A set of automated or semi-automated steps that can be assigned to a ticket.

TDX Ticket Statuses

Each ticket has a status, which technicians update to indicate progress.

New:

Indicates that work on a ticket has not been started.

Open:

Indicates that a ticket has been accepted, but that work on it has not begun.

In Process:

Indicates that a ticket has been accepted, but that work on it has not been completed.

Pending (In Process):

Indicates that a ticket has been accepted, but that work is pending the completion of some other ticket. If possible, the ticket should be updated with a comment that explains the reason for the hold.

On Hold:

Indicates that work on a ticket has been suspended but may continue later. The ticket may be waiting for a customer response, vendor response, or technical resources. If possible, the ticket should be updated with a comment that explains the reason for the hold.

Closed:

Indicates that work on a ticket has been completed.

Cancelled:

Indicates that work on a ticket was no longer needed.

Each ticket status is associated with a status class, which can be useful for reporting and filtering.

TDX statuses for each status class

Status Class

Statuses

New

New

In Process

Open
In Process
Pending (In Process)

On Hold

On Hold

Completed

Closed

Cancelled

Cancelled

TDX Ticket Classifications

Each ticket has a classification, which broadly identifies the type of work associated with the ticket.

Change:

Identifies a work order that changes the configuration or functionality of services. The “Change Management” section of this glossary goes into more detail.

Incident:

Identifies an event which caused degradation of expected services.

Major Incident (MI):

An Incident which has significant impact, and which demands a response beyond the routine Incident management process.

Examples:

  • A widely used web service is down, and many users are not able to log in.
  • A technical glitch is affecting a crucial feature and many users have reported this.
  • An unplanned technical incident that requires communication to the campus community.

Major Incidents should be promoted from reported Incidents, based on the number or severity of incoming reports. This can be particularly useful for the help desk to keep track of ongoing issues that might generate multiple tickets.

Major Incidents can contain child tickets, which is useful for tracking the severity of the issue and for communicating to affected users.

Major Incidents will be reviewed periodically by a technical working group to ensure regular monitoring, identify opportunities for improvement, and coordinate best practices.

Major Service Request (MSR):

A Service Request which has significant impact, such as requiring several hours of work or changing a system that will impact many users.

Examples:

  • A widely used web service will be retired and migrated to a new platform.
  • A project which will add, modify, or remove services, requiring 2-80 hours of work.

Major Service Requests may be subject to additional review or approval with team managers.

Release:

Identifies a software release, especially if driven by third-party service providers, that may relate to existing services.

Service Request:

Identifies a work order that falls within current services. If the work requested falls outside of current operational standards, the ticket should be promoted to a Project (see below).

Note: TeamDynamix does not always make clear the distinction between Incidents and Service Requests.

PeopleSoft Backdoor Scripts

PeopleSoft backdoor scripts are Change tickets that require an EAPP technician to make direct modifications to the PeopleSoft database. ISEC requires additional review and logging for these Changes. These backdoor scripts will be tracked by an RFC ticket that has the following tasks applied.

Technician Peer Review:

The script must be reviewed by a peer technician.

Data Owner Approval:

An appropriate data owner must approve the change.

User Approval:

An appropriate functional user must approve the change.

In addition, backdoor script tickets should have the "peoplesoft-sod" tag applied.

Major Service Requests

MSR Change Management

When the project is ready to be deployed, technicians can create an associated RFC ticket by selecting Actions -> Create Parent.

If multiple RFCs will be required, consider opening the earliest RFCs as standalone tickets and associate them with the MSR by creating ticket tasks. The final RFC can be created as a parent to the MSR.

MSR Form

In addition to the standard fields listed in “TDX Ticket Metadata”, the following is a list of fields that are specific to the Major Service Request form.

Application:

Indicates the primary application(s) impacted by this project.

Project Size:

See “MSR Project Sizes”.

Tasks:

See “MSR Tasks”.

If desired, we can add links to project files, charter, scope, communication plans, etc.

If desired, we can create multiple forms, workflows, or templates based on the Project Size field (examples: S, M, L), or based on the type of integration (examples: B2, LTI, PeopleTools). Initially we will focus on the basic process, and opportunities for improvement can be identified as we go.

MSR Project Sizes

Estimating project size enables capacity planning, resource allocation, and prioritization.

The following project size estimates are derived from the implementation details of the project. If a project meets criteria of multiple size estimates, consider estimating upward.

MSR Project Sizes

Size

Notes

Estimate

S

  • Small modifications to existing functionality
  • Architecturally insignificant
  • Only involves one Team
  • Similar to work done in the past by the Team
  • No new technologies involved
  • May require new vendor contract, CSU experience

3-9 hours

M

  • Significant modifications to existing functionality
  • Minor architectural changes
  • Only involves one Team
  • Similar to work done in the past by the Team
  • No new technologies involved
  • May require new vendor contract, CSU experience

10-19 hours

L

  • No existing functionality to leverage
  • Moderate architectural changes required
  • Multiple dependencies across 1-2 teams
  • No precedents exist for the work, or no experience on the team
  • Involves new technologies

20-29 hours

XL

  • No existing functionality to leverage
  • Major architectural changes required
  • Multiple dependencies across multiple teams
  • No precedents exist for the work, or no experience on the team
  • Involves new technologies

30-39 hours

XXL

  • Too big to size; more than one project?

40-79 hours

MSR Tasks

Work on the MSR may involve multiple teams or tickets. Creating ticket tasks can be

Work by another team or technician:

Open a task and assign it to an appropriate liaison.

Work on another ticket:

From time to time, it may be necessary to open additional tickets. When that happens, a task can be opened on the MSR to indicate the additional ticket ID. This creates a single location where all work associated with the MSR can be tracked and reported on.

IT Procurement Review

The IT Procurement Review (ITPR) process reviews information technology products to determine accessibility risk, security risk, and system compatibility. An ITPR is typically required before the university will purchase or use any IT product. See also: ITPR on the knowledge base.

HECVAT:

Higher Education Community Vendor Assessment Toolkit, a type of document that is used in security reviews.

VPAT:

Voluntary Product Accessibility Template, a type of document that is used in accessibility reviews.

SOC 2 Type 2:

A security evaluation developed by the American Institute of Certified Public Accountants, also a type of document that is used in security reviews.

 

HighPoint 

HighPoint Component Abbreviations
Component Abbreviation
Campus Experience HPT-CX
SIS Automation HPT-SA
Course AuditorHPT-CA
Degree PlannerHPT-DP
Message CenterHPT-MC
Schedule BuilderHPT-SB