ITS PRO Service Operation Ontology
- Mojgan Amini
- Lynn Underwood (Deactivated)
- Former user (Deleted)
It is important to track all effort across Project work and Service Operations work. Conveniently, the IT Services methodology is very similar for both work types.
Standardizing the service operations tracking process allows us to measure and track efforts consistently, and use data to anticipate problems or resource needs. Ultimately, it leads to improved customer service and a proven track record.
IT Services has adopted a simple methodology based on breaking down a service operations work into “what is being delivered” and “how it will be delivered”, dubbed the ITS PRO Ontology for Service Operations.
These are the key elements for service operations tracking:
OBJECTS: The tangible service offering or product being delivered to end-users. They are described using a noun, and are named after the service offering in the service catalog or operational documents used to support the service.
ACTIVITY: The action required to produce the deliverable. Activities are described using a verb. Examples of specific activities: Conduct end user training for Campus CMS, Resolve incident for Office 365.
Standard objects for Service Operations work:
Object Name | Object Type | Note | Sample Activity |
|---|---|---|---|
Roadmap for ServiceName | Roadmap | Used to track all activities related to creating, updating, and tracking a Service roadmap. Note: More info about Roadmap requirements can be found on the Service Owner Checklist [Archived 4/4/22]. |
|
CSI Plan for ServiceName | CSIPlan | Used to manage Continual Service Improvement (CSI) Plan, including creation of CSI plan, identifying opportunities for improvement, as well as defining & tracking key measures, and ultimately enhancing/improving service. Note: More info about Service Optimization and Improvement requirements can be found on the Service Owner Checklist [Archived 4/4/22] |
|
Communication for ServiceName | CommArtifact | Capture all activities related to documentation, training, and outreach for a Service. Note: More info about Communication & Awareness requirements for a Service can be found on the Service Owner Checklist [Archived 4/4/22] |
|
PR: ID - ProblemName | ProblemReport | Used to manage all activities related to conducting Problem Reviews and generation Problem Reports for a Service. Note: More info about Problem Review requirements can be found on the Service Owner Checklist [Archived 4/4/22] |
|
ServiceOfferingName | Select appropriate Object Type | For handling service incidents, answering customer questions, and service requests for a specific service offering |
|
Example Service operation structure
Example #1:
Service Name: Email & Calendaring
Service Offerings: Exchange Online, Gmail, Email Forwarding, Alumni email, Mailman mailing list,
Object Name | Object Type | Activities** |
|---|---|---|
Roadmap for Email & Calendaring | Roadmap |
|
CSI Plan for Email & Calendaring | CSIPlan |
|
Communication for Email & Calendaring | CommArtifact |
|
PR: PRB0000039 - Email delays | ProblemReport |
|
PR: PRB0000069 - Gmail not reaching campus email servers | ProblemReport |
|
Office365 Outlook | AppInstance |
|
Gmail | AppInstance |
|
Email & Calendaring Services Note: if support for multiple offerings are often treated together, then an object like this one can be created to track all support work for a group of offerings. | AppInstance |
|
Tracking After Action Reviews
Since After Action Reviews may touch several service areas, they will be managed in a dedicated AAR space in ITS-PRO (After Action Reviews). Each AAR will have it's own object as follows:
Object Name | Object Type | Tasks |
|---|---|---|
AAR: PRB0000123 - 10,000 Staff email accounts disabled for 3 hours | AARReport | Since AARs are made up of a series of formal managed steps, instead of Activities, Tasks shall be used to assign dates, estimates, and owners
|
Questions?
Contact the Service Management Office: smo@ucsd.edu