«Organizing ITSM   Transitioning the IT Organization from Silos to Services with Practical Organizational Change»
Publisher: Trafford (August 7, 2015)
Author:  Randy A. Steinberg
ISBN-10: 1490762701

О ЧЕМ КНИГА?

Рэнди Стейнберг не устает писать книги про ITSM, и последнюю свою работу посвятил вопросу внедрения практик управления ИТ-услугами как проекту трансформации ИТ-организации.
Признаюсь, прежде чем я прочел вторую часть названия книги, которая раскрывает ее цель, я лелеял надежду увидеть работу с фокусом на создание структуры ИТ-службы, определения количества персонала и т.д. Постоянно сталкиваюсь с тем, что есть запрос со стороны заказчиков к использованию формальных методов построения ИТ отталкиваясь от специфичных для отрасли рекомендаций. Но книга все же о том аспекте внедрения ITSM, который принято называть организационным изменением.

СТРУКТУРА

Chapter 1 Book Overview 
Chapter 2 Overview Of Change 
Chapter 3 The Service-Driven IT Organization Organizing 
Chapter 4 ITSM Organization Models
Chapter 5 Building The IT Organization 
Chapter 6 Dealing With Resistance Basic Causes for Resistance  
Chapter 7 Building Communications Step By Step 
Chapter 8 Stage 1 - Awareness Approach Overview
Chapter 9 Stage 2 – Strategize Campaigns 
Chapter 10 Stage 3 – Design Campaigns 
Chapter 11 Stage 4 – Conduct Campaigns 
Chapter 12 Stage 5 – Enforce Change Approach 
Chapter 13 Communication Tools and Techniques 
Chapter 14 ITSM Operating Roles 
Chapter 15 Training Considerations

МОЕ МНЕНИЕ


Автор предлагает  кампании(Campaign) как способ преобразования организации: последовательного информирования и обучения.  Довольно подробно описаны инструменты и необходимые механизмы реализации всех этапов.

Роль и обязанности service owner'а часто вызывают вопросы. Автор предлагает вот такое видение:

The service owner is responsible to the customer for the initiation, transition and ongoing maintenance and support of a particular service and accountable to the IT director or service management director for the delivery of the service. The service owner’s accountability for a specific service within an organization is independent of where the underpinning technology components, processes or professional capabilities reside. Service ownership is as critical to service management as establishing ownership for processes which cross multiple vertical silos or departments. It is possible that a single person may fulfill the service owner role for more than one service.

Key activities for the Service Owner Role include:
• Working with business relationship management to understand and translate customer requirements into activities, measures or service components that will ensure that the service provider can meet those requirements
• Ensuring consistent and appropriate communication with customer( s) for service-related enquiries and issues
 • Assisting in defining service models and in assessing the impact of new services or changes to existing services through the service portfolio management process
 • Identifying opportunities for service improvements, discussing these with the customer and raising RFCs as appropriate
 • Liaising with the appropriate process owners throughout the service lifecycle
Soliciting required data, statistics and reports for analysis and to facilitate effective service monitoring and performance
 • Providing input in service attributes such as performance, availability etc.
 • Representing the service across the organization
 • Understanding the service (components etc.)
 • Serving as the point of escalation (notification) for major incidents relating to the service
 • Representing the service in change advisory board (CAB) meetings
 • Participating in internal service review meetings (within IT)
 • Participating in external service review meetings (with the business)
 • Ensuring that the service entry in the service catalogue is accurate and is maintained
 • Participating in negotiating service level agreements (SLAs) and operational level agreements (OLAs) relating to the service
 • Identifying improvement opportunities for inclusion in the continual service improvement (CSI) register
 • Working with the CSI manager to review and prioritize improvements in the CSI register
 • Making improvements to the service
 • Serving as the point of escalation (notification) for major incidents relating to the service • Representing the service in change advisory board (CAB) meetings
 • Participating in internal service review meetings (within IT)
 • Participating in external service review meetings (with the business)
 • Ensuring that the service entry in the service catalogue is accurate and is maintained
Participating in negotiating service level agreements (SLAs) and operational level agreements (OLAs) relating to the service
 • Identifying improvement opportunities for inclusion in the continual service improvement (CSI) register
 • Working with the CSI manager to review and prioritize improvements in the CSI register
 • Making improvements to the service.

В целом, книга понравилось, много интересных моментов. Стоит потраченных денег однозначно.

Оценка: 5/5

Некоторое время назад мне довелось готовить ответ на RFP для заказчика, который хотел бы выполнить DR-проект практически полного цикла: т.е. присутствовала фаза анализа и сбора требований, а также фаза разработки решения. Почему цикл «не полный», потому что не предусматривалось внедрение и организация процесса поддержки всего этого в актуальном состоянии.
Такого рода RFP попадаются не первый раз, и подобные проекты имеют достаточно существенный недостаток на который я хотел бы обратить внимание.
С одной стороны, вроде бы логично, проанализировать требования к восстановлению ИТ и разработать архитектуру ИС, которая бы соответствовала требованиям и ожиданиям бизнеса. Но упускается важный нюанс, что, обычно, организация не имеет безразмерный бюджет на DR инициативы (и на любые другие тоже), и, скорее всего, будет попытка сосредоточиться сначала на неких mission-critical системах, потом на business-critical и т.д. Но такое деление систем, да и вообще объем работ по внесению изменений в инфраструктуру и процессы, неизвестно на этапе создания RFP, и будет понятно только после фазы анализа (BIA и анализ рисков), соответственно, попытка заставить поставщика услуг оценить затраты на фазу проектирования просто приведут к тому, что он будет закладывать риски и увеличивать длительность проекта, а следовательно и его стоимость. Поэтому такая структура проекта приводит к тому, что заказчик в итоге переплачивает.
Причины такого подхода достаточно очевидные:

• заказчик не знает как обосновать расходы на фазу анализа для бизнеса, мол нет овеществленного результата;
• хочется получить все в одном проекте;
• неизвестно будут ли деньги на другие фазы, и лучше сейчас их заложить сразу.

Если все же вышеуказанные причины нерелевантны, то есть много смысла в том, чтобы все-таки разделить фазы анализа и разработки DR-решений или системы управления непрерывностью ИТ.