|8.1Managing Change||8.2Project Mgmt||8.3Risk Mgmt||8.4Staff||8.5Technologies|
8.1 Managing Change In Service Operation
Service Operation should strive to achieve stability - but not stagnation! There are many valid and advantageous reasons why 'change is a good thing' - but Service Operation staff must ensure that any changes are absorbed without adverse impact upon the stability of the IT services being offered.
However, it is important that Service Operation staff are involved at these latter stages as they may be involved in the actual implementation and they will wish to ensure that careful scheduling takes place to avoid potential contentions or particularly sensitive periods.
8.2 Service Operation And Project Management
Because Service Operation is generally viewed as 'business as usual' and often focused on executing defined procedures in a standard way, there is a tendency not to use Project Management processes when they would in fact be appropriate. For example, major infrastructure upgrades, or the deployment of new or changed procedures, are significant tasks where formal Project Management can be used to improve control and manage costs/resources.
Using Project Management to manage these types of activity would have the following benefits: The project benefits are clearly stated and agreed
8.3 Assessing And Managing Risk In Service Operation
There will be a number of occasions where it is imperative that risk assessment to Service Operation is quickly undertaken and acted upon.
The most obvious area is in assessing the risk of potential changes or Known Errors (already covered elsewhere) but in addition Service Operation staff may need to be involved in assessing the risk and impact of:
8.4 Operational Staff In Service Design And TransitionN
All IT groups will be involved during Service Design and Service transition to ensure that new components or service are designed, tested and implemented to provide the correct levels of functionality, usability, availability, capacity, etc.
Additionally, Service Operation staff must be involved during the early stages of Service Design and Service
Transition to ensure that when new services reach the live environment they are fit for purpose, from a Service Operation perspective, and are 'supportable' in the future.
In this context, 'supportable' means:
8.5 Planning And Implementing Service Management Technologies
There are a number of factors that organizations need to plan for in readiness for, and during deployment and implementation of, ITSM support tools. These include the following.
Such tools are often sold in modular format, so the exact functionality of each module needs to be well understood and some initial sizing must be conducted to determine how many - and what type - of users will need access to each module. Licences are often available in the following types (the exact terminology may vary depending upon the software supplier).
The cost of a shared licence is usually more expensive than that of dedicated licences - but the overall cost is less as users are sharing and fewer licences are therefore needed in total.
An alternative to this is where the use of a tool is offered as part of a specific consultancy assignment (e.g. a specialist Capacity Management consultancy, say, who may offer a regular but relatively infrequent Capacity Planning consultancy package and provide use of the tools for the duration of the assignment). In such cases the licence fees are likely to be included as part of, or as an addendum to, the consultancy fee.
A further variation is where software is licensed and charged on an agent/activity basis. An example of this is interrogation/monitoring and/or simulation software (e.g. agent software that can simulate pre-defined customer paths through an organization's website, to assess and report upon performance and availability). Such software is typically charged on the basis of the number of agents, their location and/or the amount of activity generated.
In all cases, full investigations of the licensing structure must be investigated and well understood during the procurement investigations and well before tools are deployed - so that the ultimate costs do not come as any sort of surprise.
Even where network deployment is possible, this needs careful scheduling and testing - and records must be maintained throughout the rollout so that support staff have knowledge of who has been upgraded and who has not. Some form of interim Change Management may be necessary and the CMS should be updated as the roll-out progresses.
It is often necessary for a reboot of the devices for the client software to be recognized - and this needs to be arranged in advance, otherwise long delays can occur if staff do not generally switch off their desktops overnight.
There may be particular problems deploying to laptops and other portable equipment and special arrangements may be necessary for staff to log on and receive the new software.
The capacity of the network should also be checked to establish whether it can handle the transmission of management information, the transmission of log files and the distribution of clients' and also possibly software and configuration files.
A tool alone is usually not enough to make things work better. There is an old adage: 'A fool with a tool is still a fool!' The organization must first examine the processes that the tool is seeking to address and also ensure that staff are 'bought in' to the new processes and way of working and have a adopted a 'service culture'.
However, tools can and often do make things a reality for many people - they are tangible and technical staff can immediately see how the new processes can work and how they may improve their way of working.
Some processes just cannot be done without adequate tooling, so there is a careful balance to be made to ensure tools are introduced when they are needed - but not before!
Similarly, care is needed to ensure that training in any tools is provided at the correct point - not too early or knowledge will diminish or be lost, but early enough so that staff can be formally trained and fully familiarize themselves with the operation of the tools well in advance of live deployment. Additional training should be planned for an additional period when the tools go live and into the future, as needed.
In many cases a new tool will be replacing an older, probably less sophisticated, tool and the switch-over between the two is another factor to be planned.
This will often involve deciding what data needs to be carried forward from the old tool to the new one - and this may require significant reformatting to achieve the required results. Ideally this transfer should be done electronically - but in some cases a small amount of rekeying of live data may be inevitable and should be factored into the plans. Caution: older tools generally relied on more manual entry and maintenance of data so if electronic data migration is being used, an audit should be performed to verify data quality.
Where data transfer is complicated or time consuming to achieve, an alternative might be to allow a period of parallel running - with the old tool being available for an initial period alongside the new one, so that historical data can be referenced if needed. In such cases it will be prudent to make the old tool 'read-only' so that no mistakes can be made by logging new data in the old tool.
Complete details on the Release and Deployment Management process can be found in the Service Transition publication.