Evaluating UniDesk

Background

In collaboration with the University of St. Andrews and the University of Abertay, the University decided to replace their existing Call Management System with UniDesk. Unidesk is an integrated service management software package to encourage and facilitate continuous service improvement methods and measures.

It is web based and platform independent with no special add-ins and uses Shibboleth common authentication.

The University launched UniDesk on 18th November 2010.

Informatics currently use Request Tracker (RT) as a call management tool and have done so since 2002. It was initially used by the support team for IT issues but we now have 3 instances of it running and it is used extensively by IT, technical and ISS staff. It has proved to be reliable, configurable and we have undergone numerous major and minor release changes without difficulty. It is maintained by Best Practical and is a leading enterprise-grade open source issue tracking system.

This report considers whether moving from our current system (RT) to using UniDesk is a viable option and whether it would result in us providing an improved service to our users. This topic was discussed extensively at an Operational Meeting and the main points from this discussion are included in this report.

Our Options

  • 1. Stick with RT (and implicitly do first-line processing of our own calls)
  • 2. Use Unidesk, with calls going straight into an Informatics queue which we would then process ourselves. In this model, we would be considered a frontline team.
  • 3. Use Unidesk, with calls initially going to the IS Helpdesk team who would handle what they could and pass anything they couldn't to the appropriate second-line teams (including us).

Considerations

  • We shouldn't change unless the service for the users would be at least as good and ideally better.
  • If we were to use Unidesk it should be easier to pass tickets to and from IS as required.
  • We run an RT system for ISS and Forum Issues as well as for IT issues.
  • We have our own queue in UniDesk already but we would need to ensure that this was private. This impacts on how we would interact with IS-Helpline.

Possible Reasons for moving to UniDesk

  • As a general policy of moving to IS services where practical.
  • The IS Helpdesk could potentially give us some out-of-hours cover.
  • UniDesk is based on ITIL guidelines. It has a couple of useful features that we currently do not have in RT. In RT, we use three main values for status - 'new', 'open', 'resolved'. In UniDesk, however, there are a number of options for status including 'Closed - user confirmed', 'Closed without confirmation', 'Waiting on user' which potentially help with workflow. There is also a more clear cut path for escalating tickets from frontline (first line) to secondline. When firstline escalate a ticket in UniDesk, they do not lose track of it.
  • UniDesk is not only a tool for Incident management but also provides a number of other tools e.g knowledge base, problem management which may be of benefit in the future.
  • UniDesk may be extended in the future to cover other areas e.g. Release Management, Inventory management.

Reasons for staying with RT

  • IS are unlikely to be able to answer many of our calls so having our calls being processed by IS Helpline first is seen as an unnecessary step which would result in delays to our response times to user queries.
  • We would have to run an RT installation for the ISS and Forum-issues anyway, and the marginal cost of running a third is negligible. Unidesk would not be suitable for ISS use, due to DP and training issues.
  • It is impossible to follow a clear timeline within UniDesk.
  • The Request and Action windows in UniDesk are too small. Although they can be expanded, you then can't interact with the rest of the application.
  • In UniDesk, mail to a closed ticket opens a brand new ticket. In RT, it re-opens the existing ticket and mails the owner, hence keeping continuity.
  • UniDesk tickets cannot be merged unless classed as a major incident. This is a trivial and very useful function that we use regularly in RT.
  • In UniDesk, it's impossible to have multiple people cc'ed into a ticket so collaboration is difficult.
  • UniDesk doesn't have the concept of admincc. This facility in RT is used regularly.
  • By default, everyone can read Unidesk tickets. This is a matter of queue policy. We have to be aware of DP and confidentiality issues. There would be pros and cons in making our queue(s) private, and it's hard to see how we could maintain privacy if we were to use the IS Helpdesk.
  • Although UniDesk may be suitable for simple requests, it was felt that it didn't allow appropriate interaction with the end-user in cases of more complex requests.
  • We have built up an extensive knowledge base within RT over the years and therefore would want to continue running it for this purpose for a period of time. The option to import tickets from RT into UniDesk is not available.
  • In RT, all correspondence can be performed via users' and COs' mail clients. This does not appear to be the case with UniDesk.
  • Our users can currently view their tickets via the web interface. This option is not currently available in UniDesk although there are plans to make this available in the very near future. We have not seen this facility so are not in a position to comment on how suitable it might be.

Conclusions

  • Option 3 is considered not viable. It's likely to increase our response times and creates an unnecessary step which adds no value to the process. Users are unlikely to accept an additional step and resulting delays unless there's an obvious benefit. We examined a month's worth of RT tickets and came to the conclusion that the IS helpline would only have been able to assist with around 4% of the tickets.
  • Option 2 is possibly feasible for the support desk but UniDesk is unlikely to be able to provide the functionality/privacy required for the nature of tickets received by ISS. We would therefore need to continue running RT for the purpose of supporting ISS. IT staff have had the opportunity to test the functionality of UniDesk and without exception all feel that RT is more user-friendly and provides a much easier user interface. The fact that it is not possible to follow a clear timeline in UniDesk is considered to be a major issue.
  • Option 1 would therefore appear to be the most desirable at the moment. The recommendation is therefore to stick with RT and upgrade all 3 instances to the latest version (RT 4). At that point, we will review our "RT Best Practice" Guide. We need to give particular attention to how we escalate tickets between Units to ensure that all users receive a prompt response and requests do not fall through any cracks. We may also wish to consider additional options for the 'status' field.

-- AlisonDownie - 22 Dec 2011

Topic revision: r12 - 07 Jun 2012 - 08:53:52 - AlisonDownie
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies