This week, we will be mostly doing…

UAT

UAT is progressing, with most of Incident Management tested and starting on the Service Request process on Monday 29th April.  As issues are discovered and re-created by Dawn and the testing team, they are prioritised and added to a list for Lisa and Dave to work on resolving.

Email configuration

This is a time-consuming piece of work with a number of aspects to consider, including working out which steps in the processes should trigger notifications, who gets them, defining the content, configuring them in the system, then testing that it’s working – and that’s only one type of notification!  This one looks like it’s going to be with us for some time….

Dashboards

Probably the least urgent for day 1, but a really ‘nice-to-have’.  The facility to see at a glance ‘what’s hot and what’s not’ is something the old system was lacking.

Training and awareness presentations

Roy and Andy are working on the slides for the user presentations that they will be delivering from next week.  At least one of the sessions will be ReCapped.

Email

Our configuration fortnight is rapidly coming to an end but this evening, for various reasons, I’m just thinking about email.

Lisa, as planned, was busily entering the content for the system-generated notification emails when a nagging thought pushed its way to the front of my mind to throw a little spanner into the works.

After a quick chat with Paul T, who confirmed my fears (and didn’t know of any good way around them), I soon realised that we should no longer continue to forge ahead with Plan A: using mailto links to allow users (or customers, if you prefer) to automatically update their tickets via email in response to a system-generated message. I won’t go into details here of why this was plan A but suffice to say that we wanted to direct the inbound emails to specific email addresses for specific purposes. I still think it would have been a sound plan in a controlled, corporate environment; it is just not compatible with the uncontrolled nature of the University (and that’s before you even begin to consider students!).

A deeper discussion followed with Ben who had just happened to overhear some of my conversation with Paul and decided to butt in. Ben’s knowledge of email in general and the University’s email systems in particular were very helpful in steering me through all of the possibilities, weighing up the advantages and disadvantages of each, and providing an expert opinion to back up and give me confidence in the same Plan B that I had already come up with! So we are now planning to accept replies to the outbound email address and use server-side Exchange Inbox rules to redirect the messages to the specific inbound email addresses, as required. A quick look in OWA (a good tip from Ben to ensure that we’re not setting client-side rules) confirmed that this approach should work as long as we are careful with the wording of the outbound emails. I also have a partly-formulated Plan C, just in case, involving a web form accepting parameters from a link in the notification email.

Now that we had some email features to test, we asked Steve to switch on the mail services on the dev application server. He was sensibly cautious of doing this, not wanting to spam people with irrelevant emails relating to test tickets in the system about which they had knowledge. Before our consultant had left he had run a script on the database for just this kind of occasion. The script set all users in the system to not receive email. Just to make sure, I knocked up a couple of quick queries which allowed me to confirm that this setting had been applied to all but the newest members of the University, who must have been imported into the system since the script was run. Michael, our friendly DBA, re-ran the script and I could then see that no user was set to receive emails. I changed this setting just for my own account so that I would be able to see the emails.

I confirmed to Steve that I was definitely happy for him to switch on the mail services and then followed a few hectic moments. Thanks to Ursula, Gary and Adele for being on the ball and letting us know straight away that the dev system was sending out emails that it shouldn’t be.

Mild panic ensued but Paul H’s quick work helped to smoothly restore order; he provided Sharon with a list of all the 80 or so email addresses that had received a message from the dev system – luckily they were all members of ISS. Meanwhile, Sharon quickly informed the Service Desk and, after receiving Paul’s list, composed an email to all ISS staff to explain what had happened whilst Paul managed to find and remove some more messages from the mail gateway before they were delivered to the recipients. It appears that the system was trying to email all ISS staff but no-one from outside of ISS. I currently have two (or three) theories about what happened.

The main positive outcome of this was the subsequent discussion with Paul; he offered to provide us with a ‘safe’ environment for testing the emails from the system so that we can see them but they will never be delivered to the recipients’ mailboxes. This is how they test the SAP CRM emails.

The other positive I’ve taken from this is that it’s reassuring and satisfying for me to know that I work with so many experts and competent professionals.

System training

Q – Will I receive training on how to use the new system?

A – Yes, Roy Clark and Andy Proctor will deliver the training; we will contact users via email to publicise the training dates and times available.

Historic data from old system

Q – Will tickets and other data be transferred into the new system?

A – No, we won’t be migrating any historic data.  There are two options for change over: either re-enter any open tickets in to the new system (advised), or log a place-holder within the new system that refers to the ticket within the old system.  Please bear in mind that the old system will become unavailable at some point in the future (date still TBC),

Visibility of tickets owned by other teams

Q – Is there a way to retain visibility of incidents that need to be passed on to another team?

A – Yes, for ISS there is a ‘watch list’ facility which allows the analyst to monitor tickets regardless of which team they are assigned to.  There are some restrictions on this, e.g. analysts will not be allowed to see some information security incidents.

Task assignment to multiple teams

Q – Will we have the ability to assign an incident to multiple teams (e.g. when it isn’t totally clear exactly where to route an incident or an incident may need input from more than one team and both could be investigating simultaneously)?

A – Yes, for ISS the incident management process will allow ‘tasks’ to be created against the incident ticket, where the original ticket is retained by the incident owner (or team) but the tasks can be assigned to other teams.

Change and Problem Management processes

Q – Is there a recommended procedure for dealing with Changes logged as incidents or service requests in the interim until we get Change Management for ISS up and running?

A – Yes – we will have very simple Change and Problem ticket logging processes to allow creation of records.  These processes will not have any real workflow behind them to begin with; Change Management is planned to be launched in full later in 2013.

Retention of old system

Q – How long is it planned for the old system to be available?

A – That is still to be decided – we will retain it for as long as it’s needed for audit purposes, and it’s envisaged that there may be a requirement to use it as a look-up for a period after the new system goes live, however we no longer have support for the old system so we should be aware that if there are any major problems with it we may need to accept that it will no longer be useable.

 

Categories

Q – Can we add to and amend the categories over time, so that we can learn from and refine our initial set up once we have reporting analysis available?

 A – The short answer is ‘yes’ – the longer answer is we would not want to amend the categories too much/too often as this will affect trend analysis, so it’s better to try to stick with the initial set-up if possible; however there is always the option to add something in that has been missed in the initial configuration