This is all very well, but what difference do all of these measures make and are they really required for effective management of operations?

Read the case study here>>Measures for measurement sake

Introduction

Service Design can be seen as gathering functional and non-functional service needs, mapping them to the business and service requirements for integrated services, and creating the design specifications for the service assets needed to provide the services. The main aim of Service Design is to design all aspects of the required IT services, covering the application and infrastructure together with the governing IT practices, processes and policies, to realise the need and to facilitate the introduction of these services into production ensuring quality service delivery, customer satisfaction and cost-effective service provision. Service Design should also design the IT services effectively so that they do not need significant remediation work during their lifecycle.

A Service Design Document must be produced for each new service, major change to or the removal of an existing service. Ensuring that the Service Design Document details all the relevant information during the initial phase of a project prevents costly changes and rework later during the project lifecycle. The Service Design Document will detail all aspects of a service and its requirements through all of the subsequent stages of its lifecycle, it will detail all the information required on the design of the service including the required implementation and subsequent operational support.

When the Service Design Document, also commonly known as a Service Design Package, is passed to the Service Transition the Service Transition team will confirm if the Service Design Document handed over is both fit for purpose and fit for use. This ‘handover’ should be a major ‘stage gate’ for the overall project delivering the service and the ‘gate’ should not be completed until this confirmation has been received. Service Transition will build, test and deploy the new or changed service. On completion of these transition activities, control will be passed to Service Operations (following a period of early life support / warranty).

The Service Design Document is referenced through the life of the service and must be maintained through change control when any improvements or amendments to the Service Design take place. It is also recommended that the Service Design Document is audited to ensure that services in operation continue to match it.

Service Design Documents have been written in many different ways historically in organisations. Although the fundamental content of what should be included in Service Design is clearly stated within the ITIL Service Management Best Practice Guidelines, there is no defined structure of what the document should look like. The Service Design Document will interface with other documents, such as the technical architecture or technical design document. The technical design document will also form part of the overall project delivery, as it will detail the means in which the project will be delivered.

This paper aims to propose a structure of what should be included in a Service Design Document and how the document should be presented.

Service Design Considerations

Any new service should never be designed and developed in isolation. The service should be designed using a holistic approach that takes into account the overall service, the management and support systems, the technology, the service management processes and the measures and metrics. This approach will guarantee that the new service will be aligned with the current business as usual activities and that the support and operational requirements for the service are addressed from the outset.

There are four aspects of Service Design that need to be taken into account when changing or developing a new service:

The technology architectures and management systems:

To ensure that all the technology architectures and management systems are consistent with the new or changed service and have the capability to operate and maintain the new service. If not, then either the architectures or management systems will need to be amended or the design of the new service will need to be revised.

The Service Management systems and tools:

To ensure that this new or changed service is consistent with all other services, and that all other services that interface, support or depend on the new or changed services are consistent with the new service. If not, either the design of the new service or the other existing services will need to be adapted. Also the Service Management systems and tools should be reviewed to ensure they are capable of supporting the new or changed service.

The processes for supporting the day-to-day operation:

To ensure that the processes, roles, responsibilities and skills are available to operate, support and maintain the new or changed service. If not, the design of the new service will need to be revised or the existing process capabilities and/or roles will need to be enhanced. This includes all IT and Service Management processes and roles, not just the key Service Design processes.

The measurement methods and metrics:

To ensure that existing measurement methods will provide the required metrics for the new or changed service. If not, then the measurement methods will need to be enhanced or the service metrics will need to be revised.

Throughout the design phase, there is a need to show consistent value to the business. This is shown by the alignment of IT Services supporting the desired business outcomes. To enable the business to see this value the above four aspects of Service Design are embedded into key service management processes. As mentioned previously, the key processes to consider here are not just those associated with Service Design but also those associated with Service Operations and how these will be managed within Operations.

The ideal Service Design Document should be set out in such a way as to be as service specific as possible; the scope of the document should be clearly defined in the introduction and should also have very robust document editing controls. A single document may not be sufficient to cover everything needed, therefore Reference Materials will need to be referred to and controlled as part of a ‘library’ of documents. There are some key fundamental areas that need to be covered by any Service Design Document. A list of these is covered below:

Business and Service Requirements of the new service

Business and Service requirements to allow management of the new or changed service and its components, including all supporting services and agreements, control, operation, monitoring, measuring and reporting.  This will include the service functional requirements and service level requirements (including availability, the criticality and impact of the service, service hours, the business/service volumes, groups of users and how they will use the service, reporting, service reviews etc.).  Also, the operational management requirements, (including the operating and support model, supporting processes and procedures, supporting agreements, measures and metrics, stakeholder engagement etc.).

Organisation Readiness

This contains the Functional Analysis, Activity Analysis, Gap Analysis, Roles and Responsibilities and resources needed.

Service Program

An overall programme or plan covering the lifecycle of the service, including the timescales and phasing, for the transition, operations and subsequent improvement of the new service. This will include the management of co-ordination and integration, management of risks and issues, scope, objectives and components of service, skills, competencies, roles and responsibilities, supplier and contract management, communication and training plans, timescales, deliverables, targets for each stage and quality criteria for each stage.

Service Transition Plan

This contains the Build and Testing policy, Knowledge, skill and competence transfer and development, Supplier and contract transition, transition policies together with a Release strategy for the new or updated service.

Service Operational Acceptance Plan

This includes the overall operational strategy, objectives, policy, risk assessment and plans, interface and dependency planning and management, Reported Service Issues, Changes, Releases, Resolved incidents, Problems and Known Errors, Non-conformances, Warranty Period and Exit criteria, Pilot criteria and final service acceptance criteria.

Conclusions and Recommendations

To conclude this discussion paper, the best approach to take when creating a Service Design Document will be to have a holistic end-to-end perspective of what is to be designed and developed.

Be sure to go back to the Service Strategy and ensure the design is aligned to this, that it meets the business needs and objectives, and conforms to corporate and IT policies.

Attention has to be given to the level of detail to ensure that enough information for the transition and the on-going support of the service is provided.

A well-defined and thought out Service Design Document will bring a host of benefits, including assisting those involved in understanding what must be implemented into a service and if there are any questions, it is a key source of answers, reducing ambiguity on what is required e.g. by design teams and transition teams. Therefore the approach to its construction and its completeness should not be underestimated.

If you would like further details on a Service Design Document; or if you require further details on any of our consultancy services, please contact us:

Telephone: +44 (0) 207 464 8414

For more information email: info@icore-ltd.com

Introduction

Data Centers are complicated to operate and manage and are crucial to the on-going operation of the business. Businesses rely more and more on the availability and reliability of the critical IT components which typically reside within the management and control of the Data Centre.

With this in mind it is vital for Data Centre services to be managed effectively as well as efficiently by providing a reliable infrastructure for IT operations, in order to minimize any chance of disruption.

ITIL benefits within the Data Centre

There are many aspects of ITIL that are pertinent to the effective and efficient management of Data Centre services.  The most important is that it provides customer and regulatory assurances in particular with regards to aligning with the conformance of ISO27001, the information security management standard.capacity

Operationally, ITIL alignment within the Data Centre provides a number of benefits including the effective and efficient management of capacity. This includes managing floor space, power and includes UPS and generator, cooling. A Capacity Management team will often cover components such as the SAN, backup and restore timings as well as server CPU utilization and disk space; however, Data Centre specific capacity often gets overlooked by this team.

Automation is also a critical aspect in the effective and efficient ongoing management of the Data Centre, especially event management. Automation here enables a larger number of components to be monitored by fewer Data Centre operational personnel. This takes out more of the manual intervention required as well as the knowledge to understand and operate all the intricate complexities of the technical infrastructure and applications that make up the business systems and processes, if they need to be manually rectified by operators out of normal business hours. Tools used to deliver this automation need to be correctly tuned with the appropriate thresholds to ensure only the necessary events are triggered for review and management. This does require in depth business system knowledge to tune the monitoring tools appropriately.

Another of the ITIL framework components benefiting Data Centre operations is Asset Management. Effective Asset Management and tracking systems need to be in place within this environment to enable accurate management of the complex and ever changing infrastructure. This will link closely with Change and Release Management as well as assisting with an accurate CMDB and efficient Incident resolution.

Service Design and Service Transition, both covered in the ITIL framework, often overlook Data Centre operations which typically cause problems during go-live and the first few months of service operation. It is essential that Data Centre Operations are established during Service Design and also during Service Transition to ensure the Data Centre team plan for the management and control of new services that are to be supported out of the Data Centre.

In addition to the design, take on, management and support of Data Centre services, there needs to be some thought leadership and strategic direction given to Data Centre operations. This area needs to be represented as part of Service Strategy. Data Centre Strategy will include a number of considerations for ensuring Data Centre Services are optimized. Such things as standardization should be considered and agreed for platforms used within the Data Centre, builds issued, naming conventions, documentation and vendors. Ensuring standards are agreed and adopted will reduce complexities making support and management of Data Centre services a much easier and less costly task.

Conclusions and Recommendations

ITIL is definitely a framework that will improve efficiency and effectiveness of Data Centre Services for businesses of all sizes and from any industry sector. Here are a couple of examples supporting this:

Done right, use of ITIL can shave off 25% of a company’s annual IT operations expense – Forrester Research.

Rigorous ITIL practices will eliminate 60% to 90% of unplanned downtime – Enterprise Management Associates.

36% of implementers say they have improved the productivity of IT operations – Forrester.

70% have improved the quality of IT processes – Forrester.

In today’s IT environment, Data Centres should have a very tight understanding of the business requirements of the applications they are deploying and supporting, in addition to very well thought out and automated provisioning processes and tools to help the IT department quickly react and get the most from their assets. The team would also benefit from their IT department being structured to align to process rather than component silos such as servers, storage, networks, databases and applications as this speeds up the support process when escalation to 2^nd and 3^rd line teams are required. Strategically the environment should be virtualised with improved power and cooling efficiencies to provide efficiency benefits. In addition, Data Centres should aim to have industry standard hardware in addition to the adoption of the ITIL framework. Companies that are delivering these principles will benefit from:-

Higher performance,

Flexibility,

Less costly to deploy and operate

Easier to manage and support

More responsive to the needs of their business.

The most difficult obstacle in all of this is to overcome the culture and adoption of these principles by personnel within the Data Centre, because IT professionals do like to be in control of the technologies that they are supporting. The introduction of documented best practice, tools and technologies, usually creates resistance to adopting these changes. Who they are and how they work is closely allied to the tools they use as this is their knowledge and power.

Let iCore help you implement and adopt the ITIL framework within your Data Centre making it a Data Centre of the future – contact us today.

For more information email: info@icore-ltd.com

Within this paper iCore stipulated some key areas that the Customer must assure themselves are in place before they transfer service to the Cloud provider.  This paper is available at http://www.icore-ltd.com/it-service-management-for-the-cloud/

Now in our series of articles and papers for managing services in the Cloud, iCore have produced a perspective on the newly launched ‘G-Cloud’ for Central Government which looks at the service being offered and how the considerations can be applied.

What is ‘Government Cloud’?

The Cabinet Office has said that cloud services should account for 50 per cent of central government IT spending by 2015.

First iteration of the Government Cloud (G-Cloud) initiative has been launched and has been named the Cloudstore. It has 257 suppliers offering approximately 1,700 cloud computing services on year long contracts. Public sector bodies have been given the capability to write Amazon type reviews of the services they have received, which may or may not assist others in making their choices.

Examples of services offered through the G-Cloud include email, system hosting, electronic records management, data storage, and customer relationship management.

G-Cloud initiative is government’s effort to bring a broader range of suppliers and increase flexibility in procurement contracts with around 50 per cent of the suppliers on the framework small to medium businesses.

So what does iCore see as some of the benefits for the public sector and suppliers?

• For public sector – they will have more choice, only pay for what they use, understand what the costs of the product will be and exit costs from the service.
• Suppliers will benefit from lower costs of winning business.

However, with these benefits and overall approach there also come challenges.

Challenges?

So what does iCore see as some of the challenges presented?

• Comparing offerings – although early days, some are finding that the Cloudstore is designed as a catalogue for commodity products and are finding it difficult to compare companies on their offerings apart from on price. Descriptions will need to be refined moving forward to address this.
• Understanding what constitutes an end to end service – important when purchasing from a framework is ensuring all aspects of a service are being covered. The first step is to understand all aspects of the services which the IT function are offering and getting this formally documented and accessible.
• Service Integration – extremely important as multiple suppliers will be involved and include integrating existing and new services.
• Financial models will change – this means the way the IT charges internally may need to be reviewed.
• Accreditation – ensuring that services have been accredited and are at correct level for the particular public sector body.
• Location of data – ensuring that different types of data are held in a suitable location and data marked restricted or above is not off-shored.
• Service Introduction and Service Retirement need to be mature – these will be used a lot more frequently as services will be on one year contracts.
• Public Sector bodies may have less control by buying standard services – as an example, releases may be received by default (think updates to Facebook).
• Taking the SLAs offered – these SLAs may not reflect what the internal organisation wants.
• Data transfer and contract exit will need close attention – services will need to be designed with processes to allow agile movement/transfer.

How can iCore assist?

For any public sector body moving their IT services into the Cloud iCore have developed an assessment of capability that looks at both the Customer and the Provider and ensures that there are no gaps in the service management provision.  This will enable all of the considerations outlined above which need to be addressed and, while responsibilities in the Cloud environment may be redistributed, ultimate accountability rests with the business IT function.

iCore can assist with the challenges and considerations which public sector bodies now face. We have a wealth of IT Service Management experience that can be harnessed to assist public sector organisations in preparing to take and manage services from the G-Cloud.

For more information contact us at info@icore-ltd.com or call us on 0207 464 8414.+

One of the world’s largest brewing companies has embarked on a major technology restructure to rationalise, consolidate and modernise after years of acquisitions and mergers. Their overall project goal is to consolidate all of their local country SAP systems into one global system over a period of time. This is believed to be the largest SAP rollout in the world. Their final aim is to have all of the operating countries (currently 70) using the same SAP Global System.

In doing this, one of the areas that they realised needed considerable improvement was their standard Service Design documentation. This needed improved presentation, structure and content, and following the pilot implementation it was essential that this was addressed urgently for use within the Transformation Programme.

iCore’s Engagement

The brewer with their incumbent service supplier had produced their own Service Design document which was proving difficult to use and maintain and did not fully reflect the project requirements. iCore was engaged to provide a new Service Design document which more accurately reflected the current Service Design of the Global SAP System. Over a period of 8 weeks the iCore team worked with a number of the client’s key technical resources to produce a new Service Design document that met the requirements of the Transformation Programme and could be used for the subsequent releases.

Approach and Deliverables

iCore developed a new Service Design template aligned with best practice (without having access to the existing template). Utilising iCore’s FAST ITSM accelerators we produced this template within 3 days which was approved after just one review. Once approved this new template was to be used to produce the new Service Design document.

The initial draft of the new Service Design document was produced within 2 weeks, and this identified a number of flaws and gaps in the information available. iCore undertook a thorough but non-intrusive information gathering exercise over the next 4 weeks to identify the correct information and to fill the information gaps to produce a fuller Service Design document. Following a period of stringent review and clarification meetings the final version of the Service Design document was issued just 8 weeks after initiating the work package.

As an example of iCore’s thoroughness we quickly identified an inconsistency in how measures had been defined and interpreted for key business and technical SLAs and also how key technologies used in the Global Service Desk interface were not functioning as defined.

Supporting the new Service Design document iCore were also asked to provide a Recommendations Paper which documented areas for improvement in the overall management of the Global System, the quality of information available during design and introduction, and further enhancements to the Service Design template. This Recommendations Paper was delivered at the same time as the completed Service Design document.

Outcome

iCore met the requirements and produced the deliverables within an extremely short period of time in comparison to the time taken to produce the original Service Design document . In addition, iCore identified other areas of improvement that are being considered or have already been taken forward. The Service Design document is now being used as the basis for subsequent releases, and the new Service Design template will form the basis for the ‘Design Package’ to be handed over to the Service Introduction team for the next SAP release. This will assure a consistent approach in the design of the remaining SAP releases.

The brewer is also reviewing the recommendations covering their Service Operating Model to ensure these worked on not only the SAP Programme but for all projects and application releases.

As a result of the experience working with iCore we have been commissioned to provide Service Introduction support for their next releases of SAP and also are being consulted about further improvement work around Business Service Catalogue and the Service Operating Model.

Steve Ingall, Head of Consultancy, explains how to measure what matters and manage what counts.

Download pdf here.