ESS - Enterprise Systems and Services

ESS is comprised of three functional units (See our Services list below to see those groupings.)

With three separate functions, we need to remain vigilant about cross-training and adopting standards to our workflow in order to remain efficient and scalable as the University's dependence upon technology continues to grow. Over time we will focus more and more on the following axiums:

• Storage as a Service
• Services as a body of collaborative parts as opposed to the sum of discreet functions
• Simple yet Secure options for Authentication and Directory Service for both internally and externally hosted services or constituients.

We're building our practices and policies page, but unfortunately it is internal only at this point. We hope to transition it to the ITKB soon.

Our primary focus is on supporting and improving enterprise level services for the breadth of the university's constituents. As a third tier escalation point, it is our hope to focus primarily on tickets and requests that affect the entire service, or a representative population of the service. While escalation of questions that are specific to a single user or single configuration will happen, it is helpful to keep the bigger picture in mind.

In hoping to achieve that goal, we recognize that there are areas in Training and Documentation that we may assist in providing more information for our colleagues at the other support tiers at the university.

As tickets enter the ESS Queue there is currently an informal process by which they are handled:

1. Members of each functional group check the queue regularly throughout the day and pick up tickets that relate to their primary functional roles within ESS. We are working to expand the secondary functional roles, so that (for example) E-List or Proofpoint tickets can be fulfilled by many of ESS' staff instead of a smaller subset.
2. An initial judgement call is made on whether the incoming ticket is at a point that ESS should work on it. Here is some of the information we're looking to see from an escalated ticket
   • Is is related to a server that ESS provides?
   • Is this systemic, are many clients exhibiting this type of problem?
   • Is there an error message, if so, what is it.
     • Has the error message been googled, what are the top recommendations from the internet? did they work?
   • What troubleshooting steps have been taken so far with the affected users, what options have been ruled out by the current owner of the ticket.
   • Can this behavior or problem be replicated by other users, or by the technician?
   • Is the affected client's tufts username visible in the ticket fields or worklog.
3. Presuming this work is done, the ticket is then self-assigned and worked on.

There are a couple of areas of improvement that we see:

1. When a ticket doesn't meet the initial judgement call, there should be a mechanism to inform the escalating technician and then a place for this type of needed information to be collected.
2. Tickets that fail the initial judgement call are not always returned to the escalating group as quickly as possible
3. Tickets that are not systemic in nature have longer turn-around times as troubleshooting options are much more limited when we cannot replicate issues locally or require coordination with specific client testing
4. Work from home dictates maintaining the ticket queue for that day
5. Friday clean-up efforts for the ticket queue