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

Dates for the diary

Some planned dates that may be of interest:

  1. Phase 1 – Incident and Service Request management (for existing users of Service Center only)
    • Build completion – 19th April
    • UAT – 22nd April – 10th May
    • Live – 14th May
  2. Phase 2 – Self-service and Knowledgebase
    • Build completion – 12th July
    • UAT – 15th July – 9th August
    • Live – 12th August

Note: In phase 2 we will also be configuring the Change Management module for ISS to be released later in 2013

 

Why are we replacing Service Center?

I realised when I was reviewing this blog that we’d made an assumption that everyone coming to the site would know what the project was all about.  This piece is intended to give an idea of what the project is, and how it came about.

When Service Center was first implemented the requirements for system funtionality were quite different to what we need today.  The system was configured and then subsequently heavily customised to meet the needs as they were interpreted at the time.  Over the past 2 years, the system has been quite limiting in it’s ability to support our move towards a more controlled but transparent way of working.

The real deciding factor came about when HP announced that our version of Service Center was out of support.  We’d need to upgrade to remain with HP, and this meant re-working the customisations in a newer version of the product – a costly exercise.  We decided that if we were to do that, we may as well seek to replace the system with one that would support our emerging processes and give us a platform on which to build for the future.

We decided to plan to configure, not customise.  That meant that we would need to be flexible about our processes, and bend the process to fit the solution wherever possible, not the other way around. 

We went out to tender in August 2012, and with support from our group of stakeholders, procured the system we thought would represent best value for money as well as having the flexibility we need to allow us to move forward.

First steps of the system build

This week we’re working on the design of the main Incident logging process and associated screens.  This involved a one-day workshop with Pete, our LANDesk design consultant, to work out what we need, then Pete built a prototype for us to review – this was our first look at our new system – a milestone moment!

We now need to review the design document and then next week the full build of the process will be done.