Блог Романа Лобуса

Сегодня сдал экзамен IT4IT Foundation, и по горячим следам расскажу как готовился и сдавал.

Подготовка

Экзамен

На прошлой неделе принял участие в Train-the-trainer курсе по игре "The Phoenix Project" от Gamingworks. Тренинг вел Jan Schilt - один из основателей компании Gamingworks и автор игры. Все участники были из HPE, разные страны - Великобритания, Германия, Польша, Испания и даже Коста-Рика.
Игра построена на одноименной книге, которая и сделала концепцию DevOps известной - "The Phoenix Project" (Gene Kim and Kevin Behr). В ходе игры участникам нужно привести компанию к успеху увеличив прибыль и стоимость акций. Как и любая бизнес-симуляция, «Проект Феникс» не for fun, а для достижения вполне конкретных бизнес-целей: трансформация команд(ы) от силосной работы и мышления «кто-то виноват» к эффективному сотрудничеству.
Признаюсь, до знакомства с философией DevOps мне казалось, что это скорее про ПО и больше о настройке цепочки специализированного софта. Jan Schilt полностью изменил мое мнение, более того, игра и идеи, которые обсуждаются во время прохождения раундов, вообще никак не связаны с программным обеспечением. Сама игра выполнена в виде бумажных карточек=).
Сейчас, размышляя о результатах игры, прихожу к мысли, что наблюдаю у многих наших заказчиков кейс для применения идей DevOps. Взаимодействие команд разработки и эксплуатации, зачастую выглядит как вражда почище Монтекки и Капулетти, а обид и недопонимания настолько много, что все демотированы и не видят путей решения.
Коллеги сказали, что я вернулся с тренинга очень «заряженным», и это правда. Очень хочется поиграть и проверить насколько The Phoenix Project хорош в украинских реалиях.

21 июля в УЦ МУК рассказывал о новинках в сфере управления ИТ-услугами в рамках события HPE Education Brunch. Программа этого семинара включала и технические темы.

Говорил я о четырех вещах: новый курс ITIL Practitioner, IT4IT, DevOps и SIAM. В начале каждой темы спрашивал слышали ли о ней. Не столько, чтобы привлечь внимание аудитории, сколько для того, чтобы сами слушатели увидели степень осведомленности коллег. Результат, в какой-то степени, предсказуем: примерно половина участников слышали о DevOps, остальные темы были неизвестны.

Считаю, что одна из задач вендоров, это «обучать» рынок создавая осведомленность и привлекая внимание к новинкам. Таким образом, создавая новый бизнес для себя и принося пользу клиентам.

Моя презентация:

В конце мая принял участие в тренинге IT Assest Management Foundation oт ITAMOrg. Я давненько присматривался к обучению по управлению ИТ-активами. В ITIL теме ITAM уделено очень мало места, процесс SACM (Service Asset and Configuration Management) скорее про конфигурации, а не про активы. Ассоциация IATAM со сводом знаний IBPL как-то «далеко» (все тренинги, преимущественно, в Северной Америке), а сами публикации IBPL совершенно не гуманны по цене. Поэтому появление организации желающей органично занять пустое место на рынке выглядит достаточно очевидным.

На данный момент, из всей линейки тренингов можно прослушать только Foundation и Software Asset Management, остальные курсы - в стадии разработки. Доступны они или в Копенгагене (там «база» ITAMOrg ), или в Лондоне - от провайдере обучающих услуг Purple Griphon,

Я посетил курс в Лондоне, из 8 человек только я был иностранцем. Инструктор - датчанин. Сам тренинг представляет собой скорее смесь awareness-сессии и традиционного foundation c установкой понятийного аппарата и структуры. Длительность курса - 2 дня. Хотел попасть еще на SWAM, но там не собрали достаточно участников.

Курс основан на стандартах ISO 19770 и ISO 55000; по заверениям инструктора, свод знаний ITAMOrg еще в разработке, книга пишется.

К курсу предлагается экзамен. Что интересно, из восьми участников, только трое сдали (включая меня). Мне экзамен показался сложным как для Foundation, и несколько недоработанным с точки зрения консистентности - уровень материла на лекции и сложность некоторых вопросов явно не сопоставимы.

Стоит ли его посещать? Вопрос непростой, потому как курс достаточно дорогой, вопросы к экзамену еще не отполированы, а сама ценность Foundation-курса в том виде в котором он есть сейчас не очень велика, откровений там нет (что логично). Поэтому, посещать есть смысл тем, кто пресытился обучением и хочется чего-то новенького или просто уже нечего учить-)

Дополнительные материалы:
 Сайт ITAMOrg

«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-решений или системы управления непрерывностью ИТ.

«Servicing ITSM: A Handbook of Service Descriptions for it Service Managers and a Means for Building Them»
Publisher: Trafford (December 27, 2013)
Author:  Randy A. Steinberg
ISBN-10: 1490719563
ISBN-13: 978-1490719566