IT4IT Foundation - опыт подготовки и сдачи экзамена

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

Подготовка

Линейка сертификации по теме IT4IT выглядит идентично сертификационным путям Archimate и TOGAF: есть экзамен Foundation и следующая, она же последняя, ступенька - Certified. Единственное отличие, которое, по идее, должно исчезнуть в следующем году - не доступен экзамен IT4IT Certified, так как он еще в стадии разработки.Экзамен IT4IT Foundation исходя из своего названия это проверка понимания основ, или как я называю такого типа экзамены, memory test. 
Сайт OpenGroup предлагает в качестве пособия по подготовке к экзамену учебник «IT4IT Foundation Study Guide: Preparation for the IT4IT Part 1 Examination». Учебник можно купить (29.95 USD) как в электронном виде, так и бумажном. Кроме этого, доступны (купить за 0.99 USD) два варианта теста, отдельно, но, если покупаешь учебник, то там это уже все есть. 
Я обзавелся учебником. У него есть два (условных) преимущества перед чтением самого стандарта: он заметно короче, только необходимые определения в привязке к программе экзамена (syllabus); содержит тестовые вопросы в конце каждой главы и один вариант теста в конце учебника.
Потратил около недели на подготовку в достаточно расслабленном режиме - 30-40 минут чтения учебника.
Прорабатывая каждый value stream нарисовал небольшой mindmap с картой KPI, функциональных компонент и связанных с ними объектов данных.

Экзамен

Доступен пока что только у провайдера Pearson VUE, при чем нужно хитро зайти предварительно зарегистрировавшись на сайте Open Group (https://certification.opengroup.org/goto-pearsonvue). Вопросов 40, проходной балл - 26 правильно отвеченных (65%). Non-native english speakers дается еще 30 минут, совокупно 90 минут на все.
На мой взгляд, экзамен очень не сложный. Большинство вопросов о том, какие функциональные компоненты связаны с какими объектами данных, какой KPI у того или иного потока ценности, преимущества и задача потоков ценности.
Закончил за 20 минут.

В общем, с экзаменом я просто не удержался, потому как и Archimate, и TOGAF сдавал в варианте Combined (Foundation + Certified в одном заходе).  С другой стороны, появилась возможность предложить связанный курс в учебных центрах от лица HPE.

Полезные ссылки:

Posted in , , | Leave a comment

DevOps в массы

На прошлой неделе принял участие в 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 хорош в украинских реалиях.

Posted in | Leave a comment

HPE Education Brunch 2016 в Киеве

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

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

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

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

Posted in , , | Leave a comment

ITAMOrg Foundation - впечатления

В конце мая принял участие в тренинге 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

Posted in , | Leave a comment

«Organizing ITSM   Transitioning the IT Organization from Silos to Services with Practical Organizational Change» - обзор

«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

Posted in | Leave a comment

Почему не стоит объединять стадии анализа и проектирования в DR проектах?

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

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

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

Posted in , | Leave a comment

«Servicing ITSM: A Handbook of Service Descriptions for it Service Managers and a Means for Building Them» - обзор


«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


О ЧЕМ КНИГА?
Randy Steinberg, автор многих книг оканчивающихся на слово ITSM (Arhictecting ITSM, Measuring ITSM, Organizing ITSM, Implementing ITSM etc.). Очередной труд есть именно тем, что заявлено в названии, -  перечнем описаний  ИТ-услуг.



СТРУКТУРА
Главы с первой по третью раскрывают преимущества сервисного подхода, предлагают терминологию и понятийный аппарат. Главы с 4 по 10 описывают типовые сервисы, которые предлагаются ИТ-организацией. Название каждой глава представляет service line - способ группировки связанных сервисов , а содержание главы - сервисы принадлежащие этому набору.

Chapter 1 Benefits of an IT Service Approach
Chapter 2 ITSM Service Basics 
Chapter 3 Categorizing Services
Chapter 4 Technical Management Services
Chapter 5 Operational Management Support Services
Chapter 6 Service Transition Support Services
Chapter 7 Service Design and Build Services
Chapter 8 Strategy and Control Services
Chapter 9 Hosting and cloud support services
Chapter 10 IT Business Facing Services
Chapter 11 Governing Services
Chapter 12 Service Implementation

МОЕ МНЕНИЕ

Достаточное сжатое изложение ключевых принципов сервисного подхода и описания типовых сервисов. Полезна ли такая книга? Да, неплохой источник для категоризации всего, что делает ИТ. Но мне кажется автор входит в определенное противоречие самому себя верно указав в начале книги то, что каталог услуг должен отражать вклад ИТ-организации в бизнес-результаты, но подавлющее большинство описанных сервисов вряд ли напрямую потребляются бизнесом. Есть глава про IT Business Facing Services и это все. Поэтому предложенная структура, не без исключений, скорее похожа на ту часть каталога услуг, которую ITIL называет Supporting services (в противовес Customer facing services). 
Я бы сказал, что содержание книги - хорошая отправная точка для планирования содержимого каталога услуг, но все-таки не стоит забывать о том, что каталог услуг это инструмент коммуникации с бизнесом, а не только для внутреннего потребления в ИТ.
Покупать бумажную книгу я бы не стал, а вот электронный вариант вполне окупает себя.

Оценка: 3/5.

Posted in | Leave a comment

Тренинг «Advanced SFIA» - впечатления

Новый рабочий год начался с тренинга: прослушал курс «Advanced SFIA» от BSMImpact (http://bsmimpact.com/advanced-sfia-online-training/). Сам курс организован в онлайн-формате и преподается по три часа два дня подряд. Т.е. совокупные затраты времени - шесть часов плюс немного времени (~15-20 минут) на выполнение домашнего задания после первого дня.

Почему SFIA? Опыт проектов по созданию модели ИТ-компетенций показал, что SFIA очень полезный инструмент, и вполне применим на наших просторах для определения навыков и знаний необходимых ИТ-организации; описания компетенций на понятном языке как ИТ, так и HR; разделения уровней профессионализма (например, Junior-Middle-Senior), а также решения других управленческих задач.

Содержание курса

Session 1:
Integration of SFIA within HR processes
    a. Development Planning
    b. Appraisals
    c. Hiring and Recruitment
Session 2: Skills Validation and Assessment techniques (Assessors Training)
    a. Self Assessments
    b. Face to Face Assessments
    c. Interviews using SFIA
Session 3: Tools and Techniques to Support SFIA
    a. Portals and Communities of Interest
    b. Skills Inventories
    c. Workflow Management
    d. Mentoring programmes
Session 4: SFIA in Project Management
    a. Building Work Descriptions using SFIA
    b. Managing Project Risk using SFIA
    c. Management of Change and Communications using SFIA
Session 5: Operating Models, Organisational Design and FTE Rightsizing
    a. SFIA Levels
    b. SFIA Skill Families
    c. Operating Models
    d. FTE sizing technique

Что понравилось, что не понравилось:
 + раскрыты многие аспекты применения SFIA, например, в управлении проектами.
 - на мой взгляд, кое-что притянуто за уши, из-за этого впечатление все же портиться. Речь идет об организационной структуре и расчете FTE. Слайды очень общие, полезного практически - нет. Оставил в отзывах предложение либо исключить эти темы и не дезинформировать потенциальных слушателей или развить их до такой степени, чтобы информация была достаточно «тактической», чтобы использовать, а не была обобщением из открытых источников.

Дополнительные материалы:
 Ролик о том, что такое SFIA
 Программа тренинга BSMImpact



 

Posted in | Leave a comment

«Каталог услуг для успешного управления ИТ» - обзор

Дочитал, а точнее перечитал, но уже на русском, купленную в прошлом году, но ждавшую своей очереди книгу о построении каталога услуг.
Оригинальное название - «Defining IT Success Through The Service Catalog: A Practical Guide». Авторы - довольно известные консультанты в области ITSM, особенно Рой Дюмолен.
Публикации ITIL содержат крайне мало практической информации по созданию каталога услуг, задавая скорее некий базис для обсуждения и терминологию.
Книга «Каталог услуг для успешного управления ИТ», на мой взгляд, очень хороший материал для систематизации знаний в этом вопросе, и не теряет своей актуальности несмотря на то, что была выпущена в 2008 году.

Команда Cleverics выполнила отличную работу по переводу, за что им отдельное спасибо.

Моя оценка  - 5/5. Вывод: читать обязательно!

Содержание книги «Каталог услуг для успешного управления ИТ»
  • Зачем нужен каталог услуг?
    • От управления затратами — к управлению бизнес-рисками
    • От управления затратами — к управлению бизнес-ценностью
    • Начнём с каталога услуг
    • Собираем картинку: ИТ с челове-ческимлицом
    • Взгляд в будущее — Модель зрелости ИТ
    • Пример из жизни
  • ИТ-услуги
    • Этапы идентификации ИТ-услуг
    • Кто первый? Приступаем к построению каталога
  • Предложения услуг, соглашения и запросы на обслуживание
    • Услуги с точки зрения заказчиков
    • Предложения услуг
    • Установка связей сервисных предложений и ИТ-услуг
    • Связь с заказчиками — Соглашения об услугах
    • Связь с пользователями — запросы на обслуживание
    • Связь между портфелем услуг и каталогом запроса услуг
    • Качество, заметное заказчикам

  • Внедрение ITSM
    • Процесс управления уровнем услуг
    • Роли процессов управления ката-логоми уровнем услуг
    • Каталог услуг и инструментарий
  • Формирование каталога, ориентиро-ванного на бизнес
    • Определение границ ответственности
    • Интерактивность каталога услуг
    • Каталог как источник методологии
    • Бизнес-перспектива
    • Формирование бизнес-ценности
  • Шесть шагов к успеху
    • Шаг 1: Обращайтесь с пользовате-лями как заказчиками
    • Шаг 2: Стандартизируйте и опишите лучшие практики
    • Шаг 3: Определите уровни услуг
    • Шаг 4: Ценообразование и выставление счетов
    • Шаг 5: Рассмотрите возможность аутсорсинга
    • Шаг 6: Мониторинг, отчётность и совершенствование
    • Подведём итоги
  • Автоматизация
    • Фронт-офис ИТ — Точка зрения ITIL® V3
Купить книгу

Posted in , | Leave a comment

ISO/TS 22317:2015 «Societal security - Business continuity management systems - Guidelines for business impact analysis (BIA)»

Семейство стандартов посвященных управлению непрерывностью бизнеса - ISO 223xx, пополнилось технической спецификацией по проведению анализу влияния простоев на бизнес (BIA, Business Impact Analysis).



Стандарт BS ISO 22301:2012 «Societal security – Business continuity management systems – Requirements» содержит раздел 8.2.2 посвященный требованиям к выполнению BIA (авторский перевод Александра Дмитриева).
Организация должна установить, внедрить и поддерживать формализованный и документированный процесс оценки для определения приоритетов в непрерывности и восстановлении, целей и задач. Этот процесс должен включать оценку ущербов и разрушительных действий, которые сопровождают выпуск продукции и оказание услуг организации.
Анализ воздействия на бизнес должен включать следующее:
a) идентификацию действий, которые поддерживают выпуск продукции и оказание услуг;
b) оценку последствий при невыполнении в течение долгого времени данных действий;
c) установку приоритетных сроков для возобновления этих действий на определенном минимальном приемлемом уровне, принимая во внимание время время, в течение которого последствия их невыполнения станут неприемлемыми;
d) определение зависимостей и вспомогательных ресурсов для данных действий, включая поставщиков, аутсорсинговых партнеров и других соответствующих заинтересованных сторон.
Таким образом, указаны требования к результатам BIA, сам процесс должен быть задокументирован и быть поддерживаемым, но подробности выполнения анализа не описаны.

Соответствующий раздел из стандарта BS ISO 22313:2012 «Societal security — Business continuity management systems — Guidance» дает чуть больше деталей, но служить руководством к действию вряд ли может.

Традиционно, у компаний предоставляющих сервиса BIA сложилась собственная практика выполнения анализа. ISO/TS 22317 не является стандартом, т. е. нельзя провести сертификацию относительно его содержания. Этот документ выполняет функцию технической спецификации, таким образом, предлагая пример того, как можно реализовать BIA, а также помогая выполнить требования стандарта ISO 22301 в соответствующей области.

Содержание стандарта (исходя из черновика):
Foreword................................................................................................................ 4
Introduction ........................................................................................................... 5
1 Scope................................................................................................................. 7
2 Normative references .......................................................................................... 7
3 Terms and definitions...........................................................................................7
4 Prerequisites .......................................................................................................7
4.1 General .............................................................................................................7
4.2 BCM Programme Context and Scope ..................................................................2
4.2.1 BCM Programme Context................................................................................2
4.2.2 Scope of the BCM Programme ........................................................................2
4.3 BCM Programme Roles .....................................................................................2
4.3.1 BCM Programme Roles and Responsibilities....................................................2
4.3.2 BIA-Specific Roles and Competencies..............................................................2
4.4 BCM Programme Commitment............................................................................4
4.5 BCM Programme Resources ...............................................................................5
5 Performing the Business Impact Analysis............................................................... 5
5.1 Introduction ..................................................................................................... 5
5.2 Project Planning and Management ...................................................................... 6
5.2.1 Introduction (overview) .................................................................................. 6
5.2.2 Initial versus Ongoing BIA Processes.............................................................. 7
5.3 Product and Service Prioritization ...................................................................... 8
5.3.1 Introduction (Overview).................................................................................. 8
5.3.2 Inputs.......................................................................................................... 10
5.3.3 Outcomes.................................................................................................... 11
5.4 Process Prioritization ..................................................................................... 11
5.4.1 Introduction (Overview)............................................................................... 11
5.4.2 Inputs.......................................................................................................... 11
5.4.3 Outcomes.................................................................................................... 11
5.5 Activity Prioritization ..................................................................................... 12
5.5.1 Introduction (Overview)................................................................................ 12
5.5.2 Inputs......................................................................................................... 13
5.5.3 Outcomes................................................................................................... 14
5.6 Analysis and Consolidation............................................................................. 14
5.6.1 Introduction (Overview)............................................................................... 14
5.6.2 Inputs......................................................................................................... 15
5.6.3 Methods .................................................................................................... 15
5.6.4 Outcomes.................................................................................................. 15
5.7 Obtain Top Management Endorsement of BIA Results .....................................15
5.7.1 Introduction (Overview).............................................................................. 15
5.7.2 Inputs......................................................................................................... 16
5.7.3 Methods ..................................................................................................... 16
5.7.4 Outcomes.................................................................................................... 16
5.8 Next Step – Business Continuity Strategy Selection.......................................... 17
6 BIA Process Monitoring and Review ................................................................. 17
Annex A (informative) Business Impact Analysis within an ISO 22301 Business  Continuity Management System ........................................ 18
Annex B (informative) Business Impact Analysis Terminology Mapping ...........19


Дополнительные материалы:
Черновик стандарта ISO/TS 22317
Страница стандарта на сайте ISO
Вебинар PECB «Introduction to ISO 22317 – Business Impact Analysis (BIA)»

Posted in , , | Leave a comment

Вебинар «Incidents Are Not Problems – The Challenge of Causation»

David McLean - автор бизнес-романов на тему ITSM (одну из них я упоминал)  провел довольно интересный вебинар «Incidents Are Not Problems – The Challenge of Causation» на тему различий между Incident root cause и Problem root cause.




Помимо этого Дэвид предлагает скидку на покупку сразу 5 книг.



Posted in , | Leave a comment

Конференция itSMF Россия '15 - впечатления



16-18 сентября проходила очередная, 6-я конференция itSMF Россия. Впервые я посетил ее в 2012, не получилось попасть в прошлом году, и в этот раз решил не упускать возможность послушать ITSM-профессионалов и узнать,что сейчас в тренде.
Формат конференции изменился: обычно, это два дня,  в этом году - три, также появились секции с воршопами. Первый день был посвящен студентам, поэтому его я пропустил, оставшиеся два дня это день с традиционными пленарными выступлениями и секциями «по интересам», и день с воркшопами.
Среди пленарных выступлений очень интересным был доклад коллег из Cleverics о методе сервисных операций. Собственно, ему был посвящен один из воркшопов на который я, к сожалению, не попал. Теме IT4IT уделили как доклад в пленарной части, так и в секционной, что не может не радовать: видимо тема приобретает интерес со стороны ITSM-сообщества.
Как  всегда,  организация мероприятия была на высоте: отлично кормили и поили, было комфортно, правда wi-fi интернет практически не работал, что немного поломало мне рабочий конфколл в перерыве.
Что хорошего можно унести с конференции и почему я стремлюсь посещать именно это мероприятие?
 Прежде всего, это возможность послушать профессионалов и узнать что-то новое. У меня нет иллюзий насчет полноты или глубины докладов, в том смысле, что я не жду каких-то готовых и one-size-fits-all решений, но ожидаю интересные моменты, которые натолкнут меня изучать какой-то вопрос глубже. Это основная причина, которую я использую как обоснование для поездки;)
Второе - ежегодный альманах itSMF России с избранными статьями. Это то, что я уношу с собой непременно. Здесь можно посмотреть выпуски альманаха. На данный момент, альманаха за 2015 еще нет в электронном виде. Вот как он выглядит и что внутри:

И кроме всего прочего, конференция это прекрасная возможность пообщаться с коллегами, завязать новые профессиональные знакомства и задать вопросы в живую.
Этот год меня не разочаровал, надеюсь в 2016 посетить это событие снова.

Posted in | Leave a comment

«Configuration management: Expert guidance for IT service managers and practitioners. Revised edition» - обзор

«Configuration management: Expert guidance for IT service managers and practitioners. Revised edition»
Authors: Shirley Lacy and David Norfolk
Publishers: BCS
ISBN13: 9781849285148
Pages: 160
Published: 27 Jan 2014












О ЧЕМ КНИГА?

Группа профессионалов в области управления конфигурациями (CMSG) из itSMF UK подготовила сборник статей по материалам конференции, что прошла в 2008 году. Целью конференции было представить существующие практики успешных организаций, которые внедрили CMDB/CMS, а также в формате семинаров обменяться знаниями и устроить дискуссии между практиками, представителями вендоров и пользователями.

СТРУКТУРА

Структура книги соотносится с темам докладов/семинаров конференции.

1 Introduction
2 The 21st-century CMDB/CMS
3 Judging the value of CMDB/CMS
4 Overcoming the barriers to the CMS
5 Case study of a CMS implementation
6 How to improve an existing configuration management process
7 Service management requirements for a CMDB/CMS
8 Strategy and vision
9 Selecting CMS tools
10 Populating a CMDB: process design
11 Implementation
12 Good ideas... and ones to avoid -


Мое мнение:
В 2010 купил первое издание этого сборника. Обновленное издание не сильно отличается, если есть первое, не советовал бы покупать revised edition.
Книга очень хорошо дополняет материалы ITIL, которые, по моему мнению, не очень широки. Темы покрывают практически все этапы жизненного цикла проекта внедрения управления конфигурациями:от видения и стратегии до аспектов выбора ПО и внедрения. Представлен интересный инструмент оценки «качества» CMDB, критериев выбора инструмента автоматизации CMS.
В тоже время, мне хотелось бы чуть больше деталей и примеров. 

Моя оценка - 4/5.

Posted in | Leave a comment

«Integrated Measurement- KPIs and Metrics» - обзор


«Integrated measurement - KPIs and Metrics for ITSM».

Author: Daniel McLean
Publishers: ITGP
ISBN13: 9781849283830
Pages: 186
Published: 21 May 2013


Автор весьма плодовит в написании бизнес-романов на тему ITSM, и уже выпустил четыре (включая эту) книги. Главный герой - Крис, находится под угрозой увольнения, и ему необходимо успешно выполнить проект, чтобы сохранить работу. В качестве испытания Крису предложено уточнить метрики и отчетность для сервис-деска.

Мне не удалось уловить что понимает автор под integrated measurement. Ожидал увидеть что-то похожее на balanced scorecard, кстати, на обложке есть картинка напоминающая карту сбалансированных показателей, но в тексте об этом ничего нет. Если вы понимаете разницу между метрикой и KPI, а также то, что разрабатывая систему измерений следует отталкиваться от потебностей бизнеса и получателей отчетности, то можно и не читать.

Оценка - 2/5.

Несколько цитат, что мне понравились:
«...bringing impacted people into the decision process is essential, because it gives them a feeling of ownership.»
«In an ideal, academic world,” said Art. “I agree that KPIs should be measured against business or operational objectives. However, we live in the real world, and many of those objectives are nearly impossible to directly measure. How can you advocate we focus on objectives we cannot measure”? “Great question,” I said. “The key is to understand that any objective has certain things that must happen for it to be achieved. These are the critical success factors, or CSFs. If you can’t directly measure the achievement of something, measure the progress towards achieving the CSFs required to make it happen.»
«There are six things we must keep in mind when dealing with KPIs, whether they are for the service desk or the entire company, we need to consider them in a specific order, just like People, Process and Tools. I put a new slide up on the screen.
  • Understand what the business strategy or objective is, before worrying about how to measure it.
  • Decide on how to measure the data, before worrying about how to collect it.
  • Decide on how to collect the data, before worrying about how to analyze it.
  • Decide on how to analyze the data, before worrying about what is actionable.
  • Understand what your users need to take action, before designing how you report on it
  • If at any point your KPI stops making sense, either you don’t need it, or you didn’t do a good job on the previous steps.»

Posted in | Leave a comment

Новая сертификация по ITIL от AXELOS - ITIL Practioner

13 марта AXELOS объявила о выходе новой сертификации под названием ITIL Practioner, которая является промежуточным звеном между Foundation и Intemediate экзаменами, и призвана оценить знания специалиста в области применения ITIL на практике.

Так видит AXELOS фокус сертификации Practitioner:
ITIL Practitioner will focus on:
  • Giving practical guidance on how individuals can leverage Continual Service Improvement (CSI), a fundamental lifecycle stage in ITIL, to maximize the benefits of its adoption and adaption
  • Aiming to improve the capability of individuals throughout the business, to adopt and adapt ITIL in their day to day roles for maximum business benefits
  • Making use of further evolved technological capabilities - such as automation, real-time reporting and Cloud computing - to increase the quality of service design and the efficiency of service delivery
  • Leveraging other philosophies, frameworks, good practices and methodologies - including e.g. Lean, DevOps, Agile and SIAM - to further enhance the value of ITSM.

Текущую схему сертификации вполне обоснованно критиковали за то, что экзамены, да и связанные тренинги были слабо связаны с практическими вопросами внедрения практик ITSM, а больше сфокусированы на проверку знаний из книжки, что снижало полезность посещения тренингов, да и инвестиций в обучение. Появление сертификации, а также связанного с ней  учебного курса должно восполнить определенную пустоту в освещении практических вопросов использования ITIL, и сократить разрыв между «теорией»  и реальной жизнью.

Интересно, что среди заявленных особенностей сертификации упомянуты смежные методики и своды знаний - Lean, DevOps, Agile и SIAM. Будет интересно посмотреть как AXELOS видит увязывание этих техник с ITIL на практике, материалов на эту тему не так много.

Само название сертификации выглядит тоже привлекательно для тех кто ищет некого статуса, а не просто сертификата о сдаче экзамена. До появления Practioner, по сути, не было промежуточного уровня с названием типа Specialist, Auditor, Practitioner  или еще как-то. Или Expert, или кто-то в пути, но без «красивого» титула.

Интересные ссылки:
Оценка сертификации от Стюарта Рэнса (Stuart Rance) 
FAQ по сертификации (en)
FAQ по сертификации (ru) - переведен командой Cleverics

Posted in , | Leave a comment

Business Impact Analysis / Risks assessment - что сначала?

Вопрос о том, что сначала выполнять: анализ влияния (аварий) на бизнес или анализ рисков (угроз), периодически возникает среди специалистов по управлению непрерывностью бизнеса. Различные своды знаний и методологии предлагают как очередность «BIA-RA», так и «RA-BIA».

NFPA 1600 «Standard  on disaster/emergency management and business continuity programs» (Edition 2013)
«Chapter 5 Planning
......
5.2 Risk Assessment
5.3 Business Impact Analysis»

«Good Practice Guidelines 2013 Global Edition: A guide to Global Good Practice in Business Continuity»
В редакции 2013 года GPG не указывает порядок выполнения этих активностей, но последовательность описания все же намекает на видение авторов: сначала BIA, потом анализ угроз.

Автор книги «Becoming resilient», известный блоггер Dejan Kosutic
«Which comes first – risk assessment or business impact analysis? This is a question I hear a lot – ISO 22301 actually allows both approaches. However, I prefer to do risk assessment first because this way, you will have a better impression of which incidents can happen (which risks you’re exposed to), and therefore be better prepared for doing the business impact analysis (which focuses on consequences of those incidents); further, if you choose the asset-based approach for risk assessment (see section 6.2), you will have an easier time identifying all the resources later on in the business impact analysis. What you definitely shouldn’t do is perform risk assessment and business impact analysis at the same time.»

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

Зачастую, компания не располагает таким количеством ресурсов, чтобы охватить все бизнес-процессы и связанные с ними ресурсы в рамках business continuity инициативы. Приоритезация бизнес-функций (бизнес-процессов) позволяет изучать угрозы сузив область охвата анализа: начать с тех функций, что «критичней», и не подвергать исследованию все активности бизнеса, что было бы нерационально.

 Несмотря на логичность такой последовательности, я все же вижу один недостаток, который в «теории» не должен существовать, но на практике встречается весьма часто.

Выбор правильного способа восстановления бизнес-функции зависит от выдвинутых требований бизнеса ко времени восстановления. В ходе BIA это определяется показателем MTPD (Maximum Tolerable Period of Downtime). Если используется количественный подход к оценке влияния простоя, то, по идее, нужно получить  стоимость потерь для того, чтобы определить приемлемость или неприемлемость простоя для какой-то точки времени. В моей практике, бизнес либо не располагает такой информацией, либо весьма смутно представляет чего стоит простой конкретной активности для всей компании, а представители бизнеса настаивают на мгновенном восстановлении. Таким образом, показатель MTPD достаточно подвижен, и, если все же удается донести мысль, что мгновенное восстановление нерационально - например, потому что для этого нужно вложить огромные деньги, то в итоге MTPD будет определятся не риск-аппетитом компании, а сравнением затрат на DR-решение (т.е. на контрмеру) по отношению к стоимости простоя. Но контрмера зависит от риска, влияние которого мы пытаемся уменьшить, соответственно без понимания риска нужно либо выбирать одно решение для всех ситуаций, что явно нелучший вариант, либо параллельно изучать угрозы для бизнес-процесса. В итоге, определение MTPD превращается в «торг» между, например, ИТ (как владельцем ресурса) и бизнесом, где ИТ предлагает защитить бюджет под решение обеспечивающее восстановление ИТ-системы в заданное бизнесом время. А бизнес, понимая все расходы, либо расслабляет это время, если не готов оплатить предложенную смету, либо подтверждает готовность объяснить почему восстановление должно быть выполнено именно в указанное время.

Выбор «правильной» последовательности это решение, которое нужно принять индивидуально в каждом проекте. Важно понимать все последствия от выбранного порядка действий.

Posted in , | Leave a comment

ITSM: структура организации, роли и обязанности

Книжный магазин института BCS (http://shop.bcs.org/index.asp) анонсировал серию посвященную карьере в области ITSM профессий. На данный момент, выпущены книги «Business Relationship Manager», «Service Desk and Incident Manager», «Problem Manager».

«Business Relationship Manager» уже прочитан, на днях напишу о своих впечатлениях. Книжка о менеджере службы поддержки пользователей на пути к прочтению. Но больше интереса как раз к той, которая, пока что, в руки не попала: о работе менеджера проблем.

Тема построения ИТ-организации, распределения ролей и обязанностей, на мой взгляд, не особо раскрыта в литературе. Из того, что есть на рынке:

«Designing and Transforming IT Organizations»
     Author:Job ten Hagen
     Publisher:TSO (The Stationery Office)
'Designing and Transforming IT Organizations' is the introduction book to a series of (initially) six books that will provide background considerations, theory, instructions, and practical guidance for setting up organization structures in the context of improvement projects.
     Мое мнение: считать практическим руководством трудно, скорее основательное введение в вопросы создания ИТ-организации с точки зрения существующих подходов и практик.

«Service Level Management and the Service Manager»
    Author:William Redmond, Job Ten Hagen, Jan Van Bon
    Publisher:TSO (The Stationery Office)
'Service Level Management and the Service Manager ' is the second book of a series of (initially) six books that provide background considerations, theory, instructions, and practical guidance for setting up organization structures in the context of improvement projects'.
С нетерпением жду «COBIT 5 for Organizational Structures», как книги по одному из enabler.



Posted in | Leave a comment

Capability vs. Maturity assessment

В последней рассылке новостей от Центра исследований Анри Тюдора, посвященной методологии оценки процессов TIPA, есть ссылка на интервью с Аленом Рено (Alain Renault), где обсуждается разница между «capability» и «maturity» оценкой.

Вопрос и в самом деле интересный.Сами термины обычно переводятся следующим образом: capabilty - возможность, способность; maturity - зрелость. Коллеги из Cleverics провели замечательный вебинар, где эту тему раскрыли. Суть такова, что в отношении процессов корректно использовать термин «возможность», и, соответственно, проводить оценку возможностей процесса, а вот термин «зрелость» используется для оценки организации (или подразделения). Тем не менее, масса статей по тематике ITSM,  да и просто специалисты, используют выражение «оценка зрелости процессов».

Возвращаясь к интервью и методологии TIPA. Ален указывает на важное отличие (или свойство) оценки зрелости: «Maturity Assessments go a bit further and group processes in levels of maturity, which enables to get a single rating for a set of assessed processes in an organization». Таким образом, если выполнены некие условия для группы процессов, то организация оценивается как получившая определенный уровень зрелости. А вот процессы, по отдельности, могут быть оценены различным уровнем возможностей.

Зачем оцениваются возможности процессов? Что определяет полученная оценка? Уровень возможностей процесса - характеристика процесса, определяющая его способность соответствовать текущим и будущим бизнес-целям (ISO/IEC 15504-1:2004).
 Важный момент, который, по моему опыту, упускают заказчики сервисов диагностики или обследования возможностей процессов ITSM: полученный высокий уровень возможностей не гарантирует, что процесс будет в 100% случаев обеспечивать качественный результат своей работы. Высокий уровень возможностей всего лишь позволяет сделать предположение, что процесс с большей долей вероятности способен достичь поставленных целей, чем, если бы этот же процесс имел низкий уровень зрелости.

Публикация «COBIT 5: The Assessor's Guide» (раздел 1.6 The COBIT Assessment Programme Report) четко указывает на этот аспект:
«The report is not an attestation or assurance report on the effectiveness of the process or its internal controls. It is intended as an internal report to provide information for enterprise management use only and should not be relied on by others. Its purpose is to provide information about the capability of enterprise processes and to give management some indication of processes that need improvement.»


Posted in | Leave a comment

ISACA Journal Vol.4, 2014 - Governance and Management of Enterprise IT (GEIT)

Свежий выпуск ISACA Journal (Vol.4, 2014) посвящен теме ИТ-руководства.
Помимо традиционного материала для аудиторов, есть несколько статей интересных и не-аудиторам:

Leveraging Metrics for Business Innovation (Yo Delmar, CISM, CGEIT). Есть перевод на русский .
Ключевое послание - результативные метрики критичны для обеспечения согласованности (alignment) ИТ и бизнеса,  повышают операционную эффективность, а также должны стать источником «репозиционирования» ИТ как источника инноваций и конкурентного преимущества. Достижение этих целей лежит в области выбора метрик наиболее сильно связанных со стратегией компании и показателями ее производительности (эффективности).
Автор предлагает обратить особое внимание на пять аспектов проектирования полезных метрик:
  • Тон задают стратегия, цели предприятия и ключевые целевые показатели результативности.
  • Разрабатывайте метрики с учетом динамичности среды.
  • Создавайте ключевые метрики, которые будут полезны в рамках разных инициатив
  • Не забывайте про простоту внедрения
  • Сохраняйте открытость к изменениям
Не скажу, что статья совсем оригинальная, но некоторые идеи можно использовать в качестве требований при разработке метрик.

Align Business Initiatives and IT Solutions  (Ikumi Miyagi, CGEIT, CRISC, Hiroshi Monden, CISA, CIA, CRMA, Mitsuko Azuma, CISA, Reiso Kimura, CISA, CIA, Masatoshi Aramaki, CISA, CRISC, CIA, Kan Hara, CISA, CPA, and Takashi Ishijima, Ph.D., CPA)

Извечная тема согласованности ИТ и бизнеса. Японские коллеги сообщают, что 70% ИТ-проектов в Японии признано проваленными, а причины их кроются в следующем: различное видение проекта у членов проектной команды и ключевых заинтересованных сторон ввиду нечеткого определения целей проекта; ожидания менеджмента не определены на первой фазе ИТ-проекта (видимо имеются в виду инициация проекта). Предлагается решить эти проблемы с помощью каскада семинаров, начиная с топ-менеджмента до исполнителей, на каждом этапе передавая результаты в качестве входных данных для семинара более низкого уровня.
Вообще, статья сильно напомнила табличку COBIT про pain points, а также каскадирование stakeholders needs в сами знаете что.
Меня заинтересовали ссылки на некую методологию «Proper Project Plan Creation Methodology, SUSD», откуда и якобы берется решение извечных проблем. Результаты поиска небогаты, но нашелся интересный документ http://dream-biz.jp/Reiso_Kimura_Report2012.pdf . Указан один из авторов статьи.

The Business Case as an Operational Management Instrument—A Process View (Kim Maes, Steven De Haes, Ph.D., and Wim Van Grembergen, Ph.D). 
Хорошо подготовленный бизнес-кейс повышает улучшает качество принимаемых решений об инвестициях, что очевидно; тем не менее, с процессной точки зрения, организация деятельности по подготовке бизнес-кейсов зачастую не очень качественна. 
Статья содержит мнения экспертов относительное практик, которые целесообразно использовать при подготовке бизнес-кейсов. Интересное отображение предложенных практик подготовки бизнес-кейсов на процессы COBIT 5 APO04 - Manage Innovation и BAI01 - Manage Programmes and Projects.
 Сделал себе пометку вернуться при случае (подготовки бизнес-кейса) и опробовать техники, которые обозначены как наиболее результативные.

Posted in , | Leave a comment

Видеоролики про COBIT - «COBIT Distilled»

Компания Orbus Software (http://www.orbussoftware.com/), которая регулярно спамит присылает мне письма об обучающих материалах по enterprise architecture, также записала серию роликов о COBIT 5 под названием «COBIT Distilled».

Каждый из роликов это двухминутный рассказ об одном из элементов COBIT. Довольно интересный материал для визуальной демонстрации понятийного аппарата и принципов методологии.

На данный момент, освещены следующие темы:

  • What is COBIT 5?
  • What are the Benefits of COBIT?
  • Dangers of Avoiding COBIT 5
  • Comparing COBIT 4.1 to COBIT 5
  • Creating value with COBIT 5
  • COBIT 5 Principles
  • COBIT 5 Goals Cascade
  • COBIT 5 Enablers
  • COBIT 5 Enabler Dimensions and Performance Management
  • COBIT 5 Principle One
  • COBIT 5 Principle Two

Posted in | Leave a comment
Блог Романа Лобуса © 2015. Технологии Blogger.

Swedish Greys - a WordPress theme from Nordic Themepark. Converted by LiteThemes.com.