Archive for 2015

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

Дочитал, а точнее перечитал, но уже на русском, купленную в прошлом году, но ждавшую своей очереди книгу о построении каталога услуг.
Оригинальное название - «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
Блог Романа Лобуса © 2015. Технологии Blogger.

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