Поскольку посетители данного портала имеют некоторое отношение и к управлению услугами, и к организации работы первой линии поддержки, не могу не поделиться своими впечатлениями. Звонил тут как-то в банк, в котором я являюсь ипотечным заёмщиком. Технология общения с клиентом потрясает. Итак, набираю номер, мне, как обычно, отвечает робот. Далее последовательность действий следующая:

• приветственное слово (Здравствуйте, Вы позвонили, …, мы очень рады…);
• IVR 1-го уровня. Прослушиваю список, выбираю пункт «Кредиты»;
• IVR 2-го уровня. Прослушиваю список, выбираю пункт «Ипотека»;
• сообщение о том, что если я ещё не являюсь заёмщиком, я зря выбрал этот пункт меню IVR, мне здесь не помогут. Пауза;
• заверение о том, что теперь мой звонок переведён специалисту (наконец-то!). Пауза;
• неожиданно механический начальник контакт-центра предлагает мне оценить работу сотрудника (какую? какого?). Отказываюсь. Пауза;
• сообщение «В настоящий момент все наши операторы помогают другим клиентам». Мне не повезло. Зато честно. А может быть месть за то, что не оценил работу сотрудника. Длинная пауза;
• трубку снимает оператор, но к ипотеке она отношения не имеет и, внимательно выслушав мой вопрос, предлагает перевести меня на специалиста. С радостью соглашаюсь (я всё ещё надеюсь). Пауза;
• трубку снимает СПЕЦИАЛИСТ (УРА!). К сожалению, мой вопрос надо пересказывать заново – информацию ей не передали. Объясняю повторно;
• выслушав вопрос, СПЕЦИАЛИСТ просит меня назвать номер договора. Диктую и … тут звонок обрывается. Призовая игра!

Аплодисменты. Приз зрительских симпатий. Вот теперь я понимаю смысл слов, сказанных в самом начале: «Ваш звонок очень важен для нас»!

Если этот банк когда-нибудь купит мои консалтинговые услуги, я уже знаю, какую технологию работы с пользователями порекомендовать ИТ-директору. Зуб за зуб.

На YouTube.com размещено официальное приветственное видео конференции Pink Elephant'12, которая завершается сегодня в Лас-Вегасе:

Видео этого года выглядит несколько вторичным по отношению к нашумевшему прошлогоднему:

Наш портал будет внимательно следить за итогами конференции, и мы обязательно поделимся лучшими прогнозами, исследованиями и находками с нашими читателями!

А как вы думаете, чем управление активами ПО отличается от управления лицензиями? Давайте, к примеру, зайдем на сайт Microsoft, и найдем там удивительную фразу: «Управление лицензиями — это регулярный бизнес-процесс управления активами программного обеспечения в организации». Уж кто-кто, а парни из MSFT должны знать, что такое SAM. И видимо, с их точки зрения управление лицензиями – это и есть SAM.

Смотрим в стандарт ISO/IEC 19770-1: «Эффективное управление, контроль и защита активов ПО в организации». Вот как-то так. Если активами ПО управлять, то это и будет управлением активами ПО. 

А вот что про SAM говорится в IBPL: «Практика интеграции людей, процессов и технологий, которая позволяет систематически отслеживать, оценивать и управлять лицензиями ПО и использованием ПО». Правда, тут же добавляют, что «Цель SAM – сократить расходы ИТ, использование человеческих ресурсов и снизить риски соответствия требованиям регуляторов, которые наследуются от владения и управления активами ПО». Так что без этой важной оговорки практически нереально отличить, где тут управление активами ПО, а где – управление лицензиями. Хотя, надо отдать должное, в IBPL управление лицензиями определено как «процесс, контролирующий и управляющий лицензионными соглашениями».

Лично я для себя провел следующий водораздел: управление активами ПО – это такое хитрое управление лицензиями ПО, при котором мы выходим на финансовые показатели (так как финансовый аспект — это собственно то, что делает учитываемую сущность активом). Ну например. «Благодаря тому, что мы перешли на централизованную процедуру закупки, нам удалось сэкономить на ПО х миллионов». Ну или «благодаря процедурам software metering мы отказались от закупки дополнительных лицензий, что  нам  опять-таки позволило сэкономить х миллионов». То есть у нас появляются KPI, связанные с финансами.

А как бы звучала ваша версия? Особо активный получит приз - ящик пива шоколадку.

Джек Воллен, один из авторов коллективного блога портала TechRepublic.com, придумал причин полюбить конечных пользователей информационных технологий:

Работа в отрасли ИТ может перемолоть вас и выплюнуть вон. Если вы потеряли из виду людей, которые нуждаются в вашей работе и в её результатах — проще лечь на спину и поднять лапы. Как избежать этого? Нужно принять тот факт, что некоторые конечные пользователи — хорошие люди, достойные вашего уважения и дружбы. Позвольте рассказать вам о некоторых причинах моей любви к пользователям (только к некоторым... не ко всем). Может быть, что-то из этого списка вдохновит вас на проявление уважения и симпатии, которые помогут вам пережить это безумное и сложное время.

1. Пользователи нас уважают (как минимум, из-за наших технических знаний).
2. Пользователи позволяют нам не бояться безработицы.
3. Хорошо относиться к пользователям — это, вообще-то, наша работа.
4. Каждый пользователь — это чьи-то мама или папа (а не только капризный голос в трубке).
5. Пользователи не дают нам заскучать на работе.
6. У пользователей всегда хорошее настроение (конечно же это не так...но представьте, что будет, если бы вы дали им повод улыбнуться?).
7. Пользователи могут оказать вам ответную любезность.
8. Пользователи позволяют нам чувствовать себя умными, или даже волшебниками.
9. Пользователи учат нас общаться с живыми людьми, а не с компьютерами.
10. Пользователи могут стать нашими друзьями (а ведь друзей так сложно найти).

Подробные обоснования читайте в статье Джека.

А как вы относитесь к конечным пользователям? Поделитесь в комментариях!

Портал realitsm.ru имеет своё представительство в Твиттер, и является одним из немногих микроблогов про управление ИТ на русском языке.

Ну а в дополнение, мы продолжаем публиковать самое интересное в англоязычном Твиттере по теме управления ИТ за истекшую неделю:

ianclayton	99% всех учебных курсов #ITSM построены по принципу "снизу-вверх": вам расскажут, что надо делать, но никогда не объяснят — почему...
gamingpaul	За последние 4 недели говорил с 4 ИТ-директорами. Все используют термин "ИТ-трансформация", рассказывая об изменениях, необходимых для внедрения ITSm 2.0
fakeITIL	Я согласовал со своими заказчиками новые целевые сроки устранения инцидентов: Влияние1 = 2012, Влияние2 = конец 2012, Влияние3 = 2013, Влияние4 и 5 = 2014—2019 #ITSM
arjendroog	Отличная статья на entrepreneur.com о том, что такое быть настоящим посредником. Обязательно к прочтению, если вы выстраиваете свою сеть общения! http://t.co/IRLjsyhy
mattberan	Пусть ваша инструмент автоматизации ITSM станет рабом вашего процесса. А не наоборот.
aalem	@mattberan Нет, нет, нет! Пусть и инструмент автоматизации и процесс вместе будут вашими рабами.
mattberan	Давно ли вы обнимали своего менеджера инцидентов?
Bordewijk	Большинство ИТ-профессионалов не могут дать определение услуге. Посмотрите презентацию Марка и Пола: http://t.co/Wq4jo99y #itsmfweb
itsmsavvy	Если бы ИТ по-настоящему были интегрированы в бизнес, их бы не существовало в том виде, к которому мы привыкли.
theitskeptic	Закон Гилмора: Сеть расценивает цензуру как повреждение и старается её обойти .
ServiceSphere	Если вы считаете, что присутствие в социальных сетях — это участие в группах на LinkedIn... вы потрясающе управляете своим временем.

Часто приходится видеть следующую картину: деятельность регламентирована, разработаны описания, инструкции, положения, сотни страниц других документов, которые определяют что, как, кем и зачем должно делаться в той или иной области, но на практике работа отличается от имеющихся документов. 

Поэтому в ответ на вопрос "вы следуете регламенту [название]", получаю ответы: "да, но только вот тут и вот тут мы уже работаем иначе", "нет, не следуем, документ далек от практики" и т.д.

Практика показывает, что наиболее распространенные причины кроются в том, что:

1. Непонятна цель создания документа. 
2. Непонятны потребители документа.
3. Документ разработан одним-двумя сотрудниками без вовлечения в разработку всех заинтересованных лиц.
4. Документ не прошел согласование и ему не придан статус официального.

Список причин конечно можно продолжать: 

1. Не зафиксирован ответственный за обновление документа.
2. Нет триггеров и процедуры обновления документа.
3. Участники регламентируемой деятельности не информированы о существовании документа.
4. Доступ к документу затруднен.
5. Отсутствует контроль за соблюдением положений документа.

Конечно список можно продолжать. В то же время, если заранее подумать о каждом из этих пунктов, то можно избежать ненужных трудозатрат и создать нечто действительно востребованное. Вот несколько практических идей на эту тему:

1. Стоит определить цель создания документа и его потребителей. Например, если вам необходимо обеспечить единообразное выполнение процедур всеми участниками процесса, то вряд ли им стоит давать в руки пятидесятистраничное описание процесса, а вот краткая ролевая инструкция подойдет, если ее структура позволит быстро найти описание необходимых действий. 
2. В разработку документа или его согласование необходимо вовлечь ключевых специалистов, которые смогут внести в документ специфику той области в которой они работают, оценить реалистичность описываемых действий и скорректировать документ так, чтобы его требования были выполнимы.
3. Разработанный документ должен быть утвержден на уровне руководства и доведен до сведения сотрудников как обязательный к исполнению.
4. Должен быть определен порядок обновления документа и ответственный за его обновление.

Экзаменационный институт EXIN направил всем партнёрским тренинговым центрам официальные данные по обновлению экзамена MALC сертификационной схемы ITIL.

Работы по обновлению Managing Across the Lifecycle были начаты APMG в 2011 году. Приурочено обновление высшего сертификационного экзамена, конечно же, к выходу новой версии библиотеки ITIL V3 2011. В обновлении были учтены пожелания тренинговых компаний, тренеров, кандидатов и работодателей:

• Сфокусировать экзамен на управлении ИТ-услугами на всех этапах жизненного цикла
• Привязать содержание экзамена и кейса к реальным условиям и практическому опыту
• Упростить и структурировать программу обучения и экзамена и подчеркнуть важнейшие темы
• Улучшить способ формулировки вопросов и избавиться от проверки зазубривания книг ITIL V3
• Не повторять вопросы из других курсов промежуточного уровня.

APMG сообщает, что всё это было учтено, и новая программа курса (syllabus) претерпела значительные изменения. Формат экзамена тоже изменился:

• 10 заданий вместо восьми (50 баллов вместо 40)
• Вопросы теперь проверяют уровни 4 и 5 по таксономии обучения Блума (способности к анализу и синтезу материала)
• из 10 вопросов 8-10 будут иметь отношение к общему кейсу, который рассматривается в ходе сертификационного курса
• до 2 вопросов будут иметь общетеоретический характер, без привязки к кейсу
• Время, отводимое на экзамен, выросло с 90 до 120 минут (и еще дополнительно 30 минут тем, кто сдаёт на неродном языке)
• Экзамен будет основан на ITIL 2011 (это означает новые процессы BRM и Change Coordination, а также новые списки метрик и взаимосвязей между процессами)

Структура заданий не изменилась: сценарий, вопрос, 4 варианта ответа на выбор: "верный" (5 баллов), "почти верный" (3), "похожий на правду" (1) и "отвлекающий" (0).

Новый экзамен вступает в силу с 1 мая 2012 года. Проведение экзаменов по версии 2007 будет завершено 1 сентября.

Чем библиотека ITIL 2011 лучше, чем ITIL 2007? Короткий ответ: структурностью и практической полезностью. Сейчас расскажу.

Про структурность: стало однозначно лучше. Например, авторы всё-таки договорились о том, что такое "назначение" и "задачи" ("Purpose & Objectives") процесса, и согласились с Дмитрием Исайченко, что цели процесса у каждого поставщика услуг – уникальные, поэтому перечисления "Goals" теперь нет вообще. Структура описания теперь совпадает во всех пяти книгах, для всех 26 процессов.

Полезности прибавилось ещё больше. Собственно, из-за практических примеров, упоминания всевозможных прикладных техник и приёмов и вырос объём книг. Я вживую увидел это в описании процесса управления проблемами.

В версии 2007 были описаны техники диагностики проблем:

1. Хронологический анализ (Chronological analysis)
2. Анализ стоимости потерь (Pain value analysis)
3. Метод Кепнера-Трего (Kepner and Tregoe)
4. Мозговой штурм "Групповое творчество" (Brainstorming)
5. Диаграммы Исикавы (Ishikawa diagrams)
6. Анализ Парето (Pareto analysis)

А вот содержание этого же раздела в 2011 году:

1. Хронологический анализ
2. Анализ стоимости потерь
3. Метод Кепнера-Трего
4. Коллективное обсуждение идей 
5. "5-причин" (5-Why’s)
6. Изоляция неисправностей (Fault isolation)
7. Карта сходств (Affinity mapping) 
8. Проверка гипотез (Hypothesis testing)
9. Диаграммы Исикавы
10. Команда технического наблюдения
11. Анализ Парето

После описания методов размещена таблица: ваша ситуация – применимые к ней методы.

• Сложная проблема, с непонятной последовательностью ошибочных действий? Хронологический анализ и техническое наблюдение.
• Не знаете, за какую проблему браться первой? Анализ стоимости потерь и коллективное обсуждение идей.
• Непонятно, откуда начинать поиск причины? Метод Кепнера-Трего, "мозговой штурм", карта сходств и 5-Why's. И так далее, на полстраницы, мелким почерком.

В следующем посте напишу про одну из техник, которая мне особенно приглянулась.

В обсуждении заметки о принципах Service Desk 2.0 мы, мне кажется, ушли довольно далеко от изначальной мысли автора, переметнувшись в сторону мирового зла Гугла вперемежку с общим недоверием к теме — как это пользователи будут знать об ИТ-услугах больше, чем ИТ-специалисты? Да кто же им даст самостоятельно комбинировать потребление нескольких услуг, чтобы обеспечивать свои бизнес-операции? Это где ж такое видано?

Я же думаю, что мир уже изменился. Это не будущее, это настоящее, и имя ему давно известно — приложения за пределами корпоративной ИТ-инфраструктуры. Можете назвать их SaaS, можете облаками, можете сказать, что ничего нового не придумано и это старые добрые программы с интерфейсом в виде Интернет-браузера — не важно. Важно то, что они уже здесь, они используются, они важны, и ИТ-отдел о них может совершенно ничего не знать. Ни о факте их существования, ни о факте использования, ни о функциональности, ни об особенностях... Ну то есть такая же ситуация, как десять лет назад с макросами в Excel, только тогда их писали пользователи сами (или звали умного парня), а теперь этих макросов понаписали добрые ребята из стартапов. Коих (стартапов) уже сотни тысяч. Перечитайте предыдущие два слова — сотни тысяч.

Как обычно нескромно проиллюстрирую на собственном примере.

В своей ежедневной работе я использую не так много приложений — полтора десятка, наверное. Сколько из них располагается в нашей «корпоративной ИТ-инфраструктуре»? Думаю, что два: наша внутренняя ERP-CRM-управленческо-учётная-система-планирования-ресурсов, да 1С, куда же без неё. Всё остальное — за пределами. Сдача отчётности в налоговую, ПФР и прочие структуры? Веб-приложение. Клиент-банк и все платежи-выписки? Веб-приложение. Проведение вебинаров? Веб-приложение. Списки рассылки, аналитика сайтов, контекстная реклама, поручения, задачи, управление продажами? Ну, вы поняли. Чего уж там, даже обычная электропочта хостится у провайдера, а не на своём оборудовании — зачем?

Ограничения приведённого примера очевидны — размер нашей компании весьма скромен. Было бы у нас 10 000 сотрудников — собственные корпоративные системы занимали бы более значительную долю. Но кто сказал, что ITSM — это только для больших?

Внимательный читатель может предположить, что «вес» систем разный — одно дело наша ERP, другое — обычный планировщик задач и выставляльщик поручений. Хочу заверить внимательного читателя — пару дней без, например, клиент-банка нам будет не менее сложно, чем без данных о наборе на следующий учебный курс по Service Desk. Так что и маленькие программки могут быть критичными.

Теперь предположим, что мы в нашей компании отошли от принципа «минимум балласта» и у нас появился специальный ИТ-человек. Выделенный, извините за оборот. Чем он может мне помочь с этими далёкими системами? Быть «прокладкой» между мной и той поддержкой — безусловно. Помочь разобраться с базовыми вещами — как данные из одной системы залить в другую? Наверное. Да и всё, пожалуй. Хороший Service Desk получается! Полезный! Будет ли он знать об используемых мною приложениях больше, чем я сам? Или же самый важный навык оператора первой линии будет производным от глагола «to google»?

Так что меняться придётся. Хочется или нет, а ИТ-среда меняется, и ИТ-подразделение должно соответствовать. В чём-то, видимо, придётся обновить используемые практики, в чём-то придумать принципиально новые решения по работе с пользователями. Но худшее, что можно сделать, это пытаться запретить подобные маленькие программульки, чтобы у айтишников было меньше проблем. Это путь в никуда.

Или я снова слишком категоричен?

В конце января вышла в свет обновленная версия справочника ITIL® Foundation Handbook, который входит в пакет Complementary Guidance библиотеки ITIL. Это издание — лучший компаньон в подготовке к экзамену ITIL V3 Foundation для тех, кто прошёл этап живого общения. 8 февраля поступило в продажу и PDF-издание.

Социальные сети наполняются положительными отзывами. Вслед за самой библиотекой ITIL, переизданной в 2011 году, карманный справочник стал более целостным и структурированным, действительно предлагая, по словам Яна ван Бона: "самый дешёвый способ знакомства с ITIL".

Книга продаётся на официальном сайте издательства TSO Publishing в бумажном и электронном форматах (£10.95) и на Amazon.com ($19.99, пока нет в наличии).

Внимание: ISBN справочника, ориентированного на ITIL V3 2011: 9780113313495. Будьте внимательны при заказе бумажной версии.

Формат справочника: 11*14 сантиметров (четверть A4), 299 страниц, крупный шрифт.

Отличный кандидат для пополнения русскоязычной библиотеки изданий об ITSM, не так ли?

В рамках подготовки к очередной всероссийской конференции itSMF Russia 2012, Экспертный совет Форума опубликовал правила подачи материалов для очередного номера ITSM Альманаха .

Подавать материалы до 1 июля смогут авторы оригинальных статей, а также добровольные переводчики зарубежных публикаций.

По сравнению с предыдущими конкурсами по отбору статей, требования к участникам стали значительно строже:

• статьи должны быть написаны академическим стилем, и в то же время содержать практические примеры выполненных проектов (по крайней мере, таким статьям будет отдано предпочтение)
• в статье не должно быть явной или скрытой рекламы чего-либо
• объём статей: от 8000 до 40000 знаков
• указаны требования к формату статей и к вспомогательным материалам.

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

Интересный факт: авторы портала realitsm.ru принимали участие в наполнении первого и второго выпусков Альманаха.

На днях покупал в подарок мобильный телефон. Через интернет-магазин одного из основных ритейлеров, работающих со всякими гаджетами. Впечатления, как говорит Евгений, двояковыпуклые. 

С одной стороны, они молодцы: договорились с производителем, и кнопка "купить" на официальном сайте последнего ведёт прямиком в нужный магазин. Предложили несколько вариантов доставки и оплаты. И главное — телефон привезли, вовремя и без сюрпризов. 

С другой стороны, от процесса покупки у меня остались впечатления, из-за которых я, скорее всего, ещё раз в этот магазин не пойду. Откуда же эти впечатления взялись? А дело вот в чём. При оформлении заказа на сайте (а было это 9 февраля) рядом с выбранной моделью телефона было написано: "доставка 13 февраля". Это меня очень даже устраивало, и я оформил заказ. Через некоторое время мне позвонил оператор магазина для уточнения/подтверждения и стал задавать ритуальные вопросы. Один из вопросов касался срока доставки. И у нас случился такой примерно диалог:

Он: "Срок выполнения заказа — с 12 по 17 февраля. Вас это устраивает?"
Я: "Нет. меня устраивает до 14 февраля."
Он: "Хорошо.  Срок выполнения заказа — с 12 по 17 февраля. " — и переходит к следующему вопросу. 
Я: "Подождите. Скажите, а вы меня зачем спрашивали, устраивает ли меня срок выполнения заказа?"
Он : "Ну, я должен сообщить вам о сроке выполнения."

В итоге я согласился на 12-17, надеясь, что они попадут в нужный мне интервал. Телефон благополучно доставили 11 числа. Обошлось. 

К чему я рассказал эту историю? Насколько я могу судить (а я могу судить только как покупатель), один из ключевых параметров качества услуг, предоставляемых всяким интернет-магазином — пресловутая доставка "точно в срок" (JIT). Сюда входят и возможность выбрать удобный срок доставки, и выполнение согласованных обязательств. В описанном случае у меня осталось ощущение, что мне повезло, ощущение ненадёжности. И это, очевидно, сказалось на моём отношении к поставщику. 

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

И ведь вполне может оказаться, что у задачи "JIT" есть владелец-координатор, но он уверен, что всё работает как часы и использует одни и те же правила определения сроков, и данные для применения этих правил все берут из одного источника... И ведь для того, чтобы этот владелец увидел, что это, мягко говоря, не совсем так, ему всего-то и надо, что купить что-нибудь в своём магазине — и желательно, не один раз. 

Не для того, чтобы, как это модно, убедиться, что оператор не хамит и следует опроснику, а курьер соблюдает дресс-код и не вымогает чаевые. А для того, чтобы увидеть процесс, за который он отвечает, целиком, "от и до". 

Часто ли мы используем такую возможность? Часто ли инцидент-менеджер обращается за поддержкой, а менеджер изменений инициирует RFC? Мне кажется, реже, чем следовало бы...

"2012 станет годом Service Desk 2.0!" — именно так заявляет Джеймс Финистер в своём блоге CoreITSM. В рамках инициативы Back2ITSM, он разрабатывает новый подход к созданию служб поддержки пользователей.

С учётом реалий сегодняшнего дня, таких как социальные сети и BYOD, Джеймс выдвигает следующие предпосылки к обновлению:

• Пользователи будут получать доступ к услугам с помощью некорпоративных устройств: на работе, по дороге домой и дома. Отнюдь не все услуги будет предоставлять внутренняя ИТ-служба.
• Пользователи будут сами комбинировать потребление нескольких услуг чтобы обеспечивать свои бизнес-операции, примерно как электронная почта используется практически в любой деятельности.
• Пользователи будут пытаться самостоятельно получить помощь из Google или из социальных сетей перед тем, как обратиться в Service Desk, тем самым снижая объём элементарных, однократных контактов (interactions) с ИТ.
• По умолчанию, пользователи будут больше знать о своей проблеме, чем диспетчер Service Desk, который будет нагонять пользователя используя Google.
• Поскольку контакты (interactions) нестандартны, простые модели из ITIL станет сложно применять, а ещё сложнее станет выстраивать значимые метрики на них.
• Пользователи хотят чтобы их контакты с Service Desk были похожи на контакты с Apple Genius Bar, а не с операторами колл-центра.

В начале была "Служба помощи" (Help Desk). Потом ITIL "всё понял", и мы наблюдали массовое переименование Help desk в "Стол обслуживания" (Service Desk). Намерения были самыми лучшими, но мне кажется, что ожидаемой выгоды заказчики не получили: сдвиг в мышлении неудачно совпал с аутсорсингом служб поддержки в другие страны.

В ответ на это, мы должны разработать стратегию Service Desk 2.0 и:

• Признать вышеизложенный факт.
• Объединить иностранные и местные ресурсы, таким образом, чтобы контакты самообслуживания обрабатывались стандартизованными бэк-офисами Service Desk.
• Сделать так, чтобы Сервис-деск был постоянно доступен пользователям. 
• Интегрировать инновации для управления поддержкой и знаниями
• Провести пересмотр всей системы метрик, чтобы построить новую карту сбалансированных показателей
• Вооружить Сервис-деск новыми инструментами управления и дать ему дополнительную власть, чтобы избавиться от микро-менеджмента.

Подробности можно найти в статье Джеймса, изобилующей мягким британским юмором.

Портал realitsm.ru имеет своё представительство в Твиттер, и является одним из немногих микроблогов про управление ИТ на русском языке.

Ну а в дополнение, мы продолжаем публиковать самое интересное в англоязычном Твиттере по теме управления ИТ за истекшую неделю:

itgEvangelist	Формируя потребительский опыт, задавайтесь вопросом: "как о нас вспоминают?" Конкретные позитивные воспоминания приведут к новым продажам. #SAPcx
Bordewijk	Обучение сотрудников — единственный способ повысить осведомленность в вопросах безопасности: http://t.co/kg1m0f64 @christianharris & наше мнение: http://t.co/sz9CIBne
riChchestMat	Письмо от ServiceNow начинается со слов "Настает эра облаков". Не может быть! #facepalm
theitskeptic	#COBIT 5 упустил из внимания цели контроля? http://t.co/DKzq2Jhh
ServiceSphere	Сможем ли мы перескочить через "цифровую грамотность" сразу к "цифровой ответственности?"
fakeITIL	По-английски "#ITIL Foundation" звучит как название благотворительной организации помощи детям бесцельно бредущим по жизни. Я не прав? #ITSM
theitskeptic	Amazon только что рекомендовал мне мою же книгу. Угадали, молодцы.
theitskeptic	Вспомнил старую шутку: Почему акулы не едят продавцов ПО? Профессиональная этика.
Joe_the_IT_guy	Четыре главных правила #socialmedia #IT: http://t.co/nH2SSpcB
theitskeptic	Только что выложил первый бета-релиз Tipu. Было бы классно еще пару таких сделать: http://t.co/KghBhbLB
CharlesTBetz	Предположим, что мы отказываемся от использования любых инструментов, кроме электронной почты, на месяц. Потом собираем результаты. Что получится?

Роб Ингланд, более известный как ИТ-скептик, на днях опубликовал редкую для него отповедь критикам библиотеки ITIL.

Я поражаюсь, как часто произносят мантру "ITIL замедляет работу!". Нет, ITIL не замедляет. Работа по правилам — замедляет.

Есть и другие варианты: "ITIL нам мешает" или "ITIL добавляет накладных расходов". Я всегда предупреждаю своих клиентов, что использование принципов ITSM не приведёт к экономии денег. Я думаю, что те, кто продают ITSM или ITIL как инструмент сбережения средств, либо сознательно сбивают клиентов с толку, либо мало чего понимают в ITSM. Реализация мер по совершенствованию почти наверняка приведёт к возникновению новых видов работ, новых ролей и инструментов, которые уже должны были существовать у клиента.

ITIL похож на совесть. Или на маму:

• Тебе следует анализировать внешние договоры, чтобы они соответствовали тому, что ты обещал в SLA
• Все звонки нужно записывать
• Надо выполнять анализ провалившихся изменений
• Как ты собрался внедрять изменение в продуктив, не написав планов отката?
• Глупо обещать уровни доступности, если ты не умеешь их измерять
• Определяй результаты своей работы такими словами, которые будут ясны тем, кто платит за результаты
• Если не будешь фиксировать и приоритезировать все новые предложения об ИТ-системах, сразу утонешь
• Если стратегическое управление ИТ происходит за пределами ИТ — кто же решает куда тебе идти?
• Ох, если бы ты только подумал о том, как устранять крупные инциденты до того, как они случатся...
• Планы аварийного восстановления ИТ не имеют смысла без привязки к непрерывности бизнеса
• Не забывай чистить зубы

Подробные аргументы читайте в блоге Скептика.

Мы как-то уже делали интеграцию OMNITRACKER с АТС по обработке входящих звонков. Схема стандартная. Идёт звонок, агент АТС вызывает обработчик, который по телефонному номеру находит пользователя и открывает его карточку в OMNITRACKER. Соответственно, сразу и текущие обращения видны, и новое одним кликом можно создать (разумеется, с предзаполнением заявителя).

Но вчера по запросу одного из потенциальных клиентов мы за несколько часов собрали аналогичное по функциональным возможностям решение по интеграции со скайпом. При входящем звонке через скайп появляется диалог с запросом, надо ли обрабатывать звонок в OMNITRACKER. Если оператор отвечает утвердительно, автоматически снимается трубка в скайпе (начинается разговор), а параллельно по skype id находится пользователь в OMNITRACKER. Причём skype id в OMNITRACKER может храниться просто как ещё один телефонный номер с подтипом «Skype» – полная унификация

Просто не мог не похвастаться. Всё штатными средствами – и со стороны Skype, и со стороны OMNITRACKER. Никому не надо?

Активный участник обсуждений на нашем портале задал нам вопрос, который, с его согласия, мы хотели бы переадресовать вам, для получения объективной картины мнений:

Я работаю в  территориально распределенной компании. Структура управления жестко функциональная, бюрократическая с сильными вкраплениями прямого управления со стороны функциональных директоров. И, хотя у нас есть некоторые процессы управления в ИТ службе и достаточно давно, мы решили сделать такую штуку как OLA только сейчас. Оно, OLA, правда нужно в работе. Так сказать доросли.

Написали. Согласовали между собой и отдали оформлять приказом. Приказом, чтобы сомнений ни у кого не было, ибо ПЕЧАТЬ на документе. И тут оказалось, что у юристов свой взгляд на проблематику и "в гробу они видали все ваши айтилы-шмайтилы" и что "заключать соглашение о предоставлении услуги между двумя подразделениями логически не верно, потому что есть функциональная ответственность, положения о подразделении и должностные инструкции". Короче, они не сдались даже после того, как мы залочили им интернет под предлогом вирусной атаки.

Собственно вопрос:

А какова действительность в российских и западных компаниях по этому поводу. Можно конечно просто самим договориться, подписать или руки пожать и пойти работать, соблюдая договоренности. Но по-моему это просто создание новых политик в компании. "Делаем так, а так нив коем случае". Смысл аббревиатуры OLA по-моему  не в этом. А вы как считаете?

Итак, кому удалось повидать этого диковинного зверя — OLA — вживую, в естественной среде обитания: поделитесь, пожалуйста, своим опытом в комментариях!

Наш короткий опрос успешно завершён. Всего за одну неделю мы собрали почти 200 мнений, которые, безусловно, повлияют на нашу "редакционную политику".

Мы предложили двенадцать тем, и каждый голосующий мог выбрать столько из них, сколько считал заслуживающими внимания. Вот итоги опроса:

Тема, которая вышла в лидеры, уже запланирована — 16 февраля мы проводим первый вебинар из нашей новой серии, регистрация на который уже открыта.

Забавно, что большинство тем получило примерно одинаковое количество голосов — похоже, мы угадали с направлением. Это косвенно подтверждается ещё и тем, что 9% опрошенных выбрали почти все предложенные темы.

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

Да, и помимо регистрации на первый вебинар мы также открыли регистрацию на второй и третий.

До встречи!

Продолжаем публикацию материалов по измерению процесса управления инцидентами. Чтобы предотвратить «футбол» (быстрое, бездумное перекидывание инцидентов в другие группы) плюс к метрике своевременности (которая бурно обсуждалась в заметке «Измеряем Incident management») нужна вторая метрика – результативности. О ней и поговорим в этой заметке.

Традиционно одна из метрик управления инцидентами была посвящена контролю возвратов на доработку и рассчитывалась по формуле «доля инцидентов, возвращённых на доработку, от общего количества инцидентов, решённых за период». В чём недостатки такой метрики? Их (как минимум) два:

• её трудно связать с группой специалистов. В самом деле, после возврата на доработку инцидент фактически мог быть решён другой группой – не той, которая отрапортовала о неверном решении и привела к возврату на доработку;
• эта метрика учитывает только передачу решения заявителю, но не учитывает внутренние передачи инцидентов между группами ИТ. Однако внутренние передачи инцидентов также могут быть нерезультативными, то есть увеличивать общее время обработки.

Для преодоления этих недостатков необходимо выполнять расчёт не по записям инцидентов, а по истории их обработки рабочими группами. Тогда по каждому решённому за период инциденту можно посчитать, сколько раз та или иная группа участвовала в его обработке. Если участвовала больше одного раза, значит инцидент передавался этой группе повторно. Значит, с первого раза была сделана не вся необходимая работа.

Тогда по каждой из групп метрику результативности можно представить в виде:

где  – KPI группы по результативности обработки инцидентов;

N – общее количество инцидентов, решённых за период (с участием данной группы);

M – количество инцидентов, потребовавших повторной обработки силами данной группы.

Как обычно, метрика нормирована в диапазоне [0; 1]: 1 – отлично, 0 – наихудший результат.

ВАЖНО. Данная метрика применима только при соблюдении следующих условий:

• процесс должен использовать переназначение инцидентов только для функциональной эскалации. В моей практике встречались и другие случаи. Вот некоторые примеры:
  • возврат на Service Desk при передаче решения пользователям;
  • возврат группе, отвечающей за прикладное ПО, после устранения инцидента в базовой инфраструктуре;
  • последовательное переназначение инцидента (или обращения пользователя), требующего выполнения работ силами нескольких групп;
• при возврате инцидента на доработку (отказ пользователя) он должен изначально попадать на обработку той же группе, которая сообщила о решении (встречал случаи возврата на Service Desk, что лично мне кажется не очень логичным).

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

P.S. В следующей заметке я вернусь к тому, как из нескольких метрик (в нашем примере – метрики своевременности и результативности) можно сделать один KPI. И если Вы сразу готовы предложить среднее арифметическое, не спешите

Портал realitsm.ru имеет своё представительство в Твиттер, и является одним из немногих микроблогов про управление ИТ на русском языке.

Ну а в дополнение, мы продолжаем публиковать самое интересное в англоязычном Твиттере по теме управления ИТ за истекшую неделю:

stephenmann	Комитеты: туда уходят умирать хорошие идеи. #внезапнопришловголову
theitskeptic	Очень хорошие отзывы от читателей #Tipu. Теперь нужно, чтобы методом начали действительно пользоваться, обкатали его...
fakeITIL	Ужасно, что я такой противоречивый. Мне нравится.
pinkerdavid	Если вы любите цитировать определения Изменения из всех трёх версий #ITIL, то скорее всего вы #ITIL-колхозник http://t.co/vGCrjKbx
pinkerdavid	Если на заседание CAB вы берёте монету с двумя решками, то скорее всего вы #ITIL-колхозник (спасибо @Jackprobst) http://t.co/vGCrjKbx
Joe_the_IT_guy	"Работайте для ваших клиентов, а не для прессы или директоров. Конечный пользователь — вот кто имеет значение в долгосрочной перспективе" @garyvee
riChchestMat	Иногда Твиттер напоминает мне, что всё-таки у меня есть стандарты.
guv_girl	Я таких людей знаю: RT @demingsos "Он использует статистику как пьяница — уличные фонари: для поддержки, а не для освещения" Andrew Lang
G2G3	Даже моему Твиттер-клиенту не нравится слово gamification. Я его понимаю.
mattberan	Наверное, проще написать книжку про НЕправильные процессы. Интереснее читать и похоже на правду. #конечношучу
mattberan	Если пользователь сам решил свою проблему и не стал звонить в ИТ — это инцидент или нет?
SMArtITmgmt	Мы только что получили Карманные Основы #ITIL издательства TSO. В карман вряд ли влезет: http://t.co/1IxriyqR

Компания Cleverics сообщает о выходе нового отечественного решения для автоматизации управления ИТ-услугами. CleverENGINE 2012 стал логическим развитием отлично зарекомендовавшего себя на рынке продукта на платформе OMNITRACKER. CleverENGINE является разработкой консультантов компании Cleverics, основанной исключительно на реальном проектном опыте и на настоящих требованиях российских заказчиков.

В CleverENGINE 2012 появилось много интересного, и востребованного клиентами:

• Учёт времени пребывания объектов на каждой группе поддержки
• Умный интерфейс для инцидентов и других событий из систем мониторинга
• Автоматическое присвоение категории инциденту в зависимости от КЕ
• Новый интерфейс специально для руководителей команд ИТ

Об этих и других нововведениях читайте в официальном пресс-релизе.

Количество российских компаний, сертифицировавших некоторые свои услуги по стандарту ISO 20000 надёжно перевалило за тридцать.

BSI выпустила сертификат для Среднерусского банка Сбербанка России, свидетельствующий о соответствии системы управления услугами требованиям стандарта ISO/IEC 20000-1:2005 для "услуг по эксплуатации и сопровождению критичных автоматизированных банковских систем, предоставляемых структурным подразделениям Среднерусского банка".

Поздравляем коллег с обретением сертификации, желаем не останавливаться на достигнутом.

С нетерпением ждём первой компании, сертифицированной по обновлённому в 2011 году стандарту.

На портале realitsm.ru вы всегда сможете ознакомиться с полным реестром российских обладателей сертификатов ISO 20000.

В последнее время все чаще обращаются заказчики с желанием самостоятельно спланировать/разработать/внедрить процессы с минимальным консалтинговым сопровождением. "Вы нам тулу хорошую дайте, ну и как-нибудь помогите еще, так, чтоб заработало". Желание понятное.

Понятны и риски — у заказчика при самостоятельном внедрении шансы на неуспешное завершение проекта возрастают. А консультанты при таком раскладе зарабатывают меньше денег и получают дополнительные репутационные риски, ведь при неудаче никаким договором не прикроешься, все будут знать: внедряли вот эти, а помогали им — вот эти.

И что интересно — стали часто просить "стандартный процесс". Есть ощущение, что это тренд. Вперед, к решениям из коробки с минимальным процессным консалтингом? Рынок меняется?

Я очень хотел написать серьёзный пост. Про метрики, все дела. Сам понимаю, что период постновогоднего стёба несколько затянулся. Но открыл новости ... и не смог. А как пройти мимо такого? РПЦ освящает в Москве катки, чтобы сделать их менее травмоопасными. Цитата: "Освящение льда делается для того, чтобы снизить травмоопасность. На наших зимних праздничных мероприятиях всегда присутствует батюшка, он освящает лед, проводит молебен ... Вчера за все время народных гуляний не было зафиксировано ни одной травмы. Хочется верить, что это потому, что лед был освящен".

Это ж какой неисчерпанный (а может и неисчерпаемый) резерв? Священнослужитель освящает ваши информационные системы и они становятся надёжней. Количество инцидентов сокращается. Качество услуг растёт. Быстро, без хлопот, недорого. Потом можно будет и за мозги взяться... Ну позовите уже кто-нибудь, расскажете потом о результатах!

Осенью прошлого года компания Cleverics провела серию ITSM-вебинаров, в каждом из которых в простой и доступной форме консультанты и тренеры делились своими секретами, наработками и практическими идеями по организации того или иного аспекта управления ИТ. Мы получили множество положительных отзывов и благодарностей, а наше "вещание" посмотрело несколько тысяч человек.

Теперь пришла пора продолжения, с февраля 2012 мы начинаем новую серию вебинаров CleverTALK. В этот раз расписание будет составлено самими участниками — на сайте Cleverics организовано голосование за темы новых вебинаров.

Пройдите по ссылке и оставьте свое мнение!
(на это потребуется не более пяти минут)

Кстати, там же доступны аудиозаписи и презентации всех предыдущих вебинаров.

Сегодня у меня день рождения. Если верить статистическим данным о продолжительности жизни в России, рубеж  в полжизни я перешагнул несколько лет назад. Четверть жизни я занимаюсь ITSM. То есть даже если прямо завтра перестану и кардинально поменяю род занятий, около 1/8 отпущенного мне срока я уже необратимо посвятил этим четырём буквам. Любопытно оглянуться. 

Почему-то первое, что приходит в голову — ёлки-палки, где я только не был за эти годы! От Владивостока до Гааги и от Мончегорска до Алматы. В большинстве этих мест я никогда не побывал бы, если бы не работа, и большинство из них стоит того, чтобы там побывать. ITSM сделал из меня путешественника.

До знакомства с ITIL я несколько лет не пользовался английским и, конечно, всё забыл. Пришлось вспоминать — слушать курсы, читать книжки, общаться с замечательными голландцами... Сейчас мы переводим на русский статьи и книжки и проводим на английском тренинги. У меня появилась колонка на itsmportal.com. Я начал читать на языке оригинала бизнес-книжки и любимые художественные. ITSM вернул мне в голову английский язык.

Ещё пришлось многому научиться — в большом и малом, в отношениях с людьми, организации работы, выполнении отдельных прикладных задач... ITSM дал мне много знаний и умений — помимо  определённой компетенции в самом управлении ИТ-услугами, разумеется.

Мы познакомились с несколькими тысячами человек, приходивших на курсы. Статистичеси это невероятно, но среди них не было ни одного злобного идиота (никак не могу сказать того же о других областях, в которых мне приходилось работать). Профессиональное сообщество, в котором мы все существуем, в основном состоит из интересных, профессиональных, симпатичных людей, с которыми чрезвычайно приятно общаться. Яркий тому пример — посетители и участники дискуссий здесь, на Real ITSM. ITSM дал мне комфортную среду для профессионального общения. 

И самое главное — я занимаюсь любимым делом не один, а вместе с друзьями — верными, сильными, готовыми придти на помощь. Дать совет или по шее, в зависимости от обстоятельств. Мне кажется, это редкостная удача и, возможно, главное, что дал мне сделанный почти десять лет назад выбор профессии. За друзей и выпьем! 

Портал realitsm.ru имеет своё представительство в Твиттер, и является одним из немногих микроблогов про управление ИТ на русском языке.

Ну а в дополнение, мы продолжаем публиковать самое интересное в англоязычном Твиттере по теме управления ИТ за истекшую неделю:

stephenmann	“Нам следует честно говорить об ITIL” | @Forrester Blogs http://t.co/hdjKnjZH #ITSM #ITIL #Back2ITSM
probsolveit	Новая попытка описать разницу между Управлением Инцидентами и Управлением Проблемами ITIL v3 здесь http://t.co/v64AZT8o
theitskeptic	Заметил тенденцию — книжки и буклеты по ИТ всё больше похожи на детские книжки: яркие цвета, большие буквы, много картинок. Отупляет.
theitskeptic	Возникло желание заменить систему для Сервис-деска?Спорим, это от того что давно не обновлялись? Да и вообще — ваша проблема не в ней.
aalem	Нам нужно придумывать новые модели, чтобы решать новые задачи #ITSM. Трудновато, ведь мы всё ещё ковыряемся с #ITIL.
pinkerdavid	pinkerdavid: Great overview of #ISO20000 by @JackProbst http://t.co/eV7hvbKm Why aren't more in US & Canada interested in ISO 20k? #ITSM
theitskeptic	Глава 5 из #ITIL Service Strategy 2011 крутая. Мне нравится.
mattberan	Занялся консалтингом. Хочется обнимать людей.
mattberan	Только что познакомился с менеджером инцидентов, который носит с собой секундомер. Гениально.
theitskeptic	Вот тут отлично изложены главные изменения в #ITIL 2011: http://t.co/CQSiV1wx
stephenmann	Понимаешь, что в браузере сидишь слишком много, только когда пытаешься обновить страницу в MS Word. #внезапно
pinkerdavid	Для меня полная загадка, почему #IBM #BMC #HP и #CA не присоединились к более чем 40 #ITSM конкурентам на #PINK12 http://t.co/Tc9RyWBl #КакДела?
pinkerdavid	Много читаю про #GreenIT в смысле энергозатрат на эксплуатацию. А как насчёт влияния на окружающую среду ДО первого включения в розетку?

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

Почитать на эту тему можно у знатоков (Роб Ингланд, Джеймс Финистер, Евгений Шилов и другие), а отследить волну щебета, хотя бы у нас на портале realitsm.ru, в Дайджесте ITSM-твитов.

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

Тот же Джеймс Финистер указывает семь:

• Сбор "разведданых" о пользователях: их желаниях, степени удовлетворённости, и даже о конкретных сервисных инцидентах
• Проверка идей: например, опросы типа "Что вы скажете, если мы прикрутим к нашей электронной почте ЭЦП?"
• Коммуникации с пользователями: оперативные и маркетинговые, с активной обратной связью
• Выстраивание отношений с пользователями и заказчиками
• Выстраивание сообществ (про кладбище сообществ писал не так давно Роб Ингланд)
• Обучение пользователей. Включая самообучение и передачу знаний между пользователями. Опасная штука.
• Gamification (поостерегусь пока переводить это замечательное слово; здесь оно используется узко: накопление "кармы" и авторитета в социальной сети, к чему могут стремиться некоторые пользователи, ну как на Хабрахабре).

Из такого списка, в России на текущем уровне развития мне кажутся приземлёнными и приносящими пользу быстро только такие:

• Отслеживание информации от пользователей в открытых сетях. Этим уже сегодня занимаются крупные компании, и специальные подразделения. Если говорить о внутренних поставщиках, то вряд ли стоит тратить усилия на отслеживание такой информации. А поставщики, работающие на открытый рынок, особенно системные интеграторы, конечно же должны вести такую работу. Тем более, что мы знаем, как их услуги выбираются.
• Общение поставщика услуг и пользователей. Это использование социальных сетей применимо больше для внутренних поставщиков, когда в интранете компании возможна организация форумов или личных сообщений, сбора предложений и идей от пользователей, публикация отчётов по работе ИТ обязательно с функционалом комментирования.

Как и всегда, реализовывать эти рекомендации следует, если ожидается действительно существенная информация и обратная связь от сообщества пользователей. А после реализации поставщик услуг должен делать так, чтобы сеть продолжала работать. Это сложная задача: большинству пользователей "некогда, работать надо!", а топливом для самообеспечения сообщества пользователей может служить только недовольство поставщиком услуг. Шутка.

И главное, в чём я полностью согласен с дядей Робом Ингландом: социальные сети — это "модная игрушка", технология. А технологии в ITSM, как известно, только на третьем месте, после людей и процессов...

Как считаете?

Коллеги, вот скажите мне, кто эти люди? Кто должен проверять актуальность CMDB? Не то чтобы у меня совсем не было идей, просто интересно узнать ваше мнение.

Напомню, что в процессе управления конфигурациями предполагается периодическая проверка актуальности хранящихся в CMDB данных. Проверка может быть полной, может быть выборочной. Результатом проверки обычно является перечень выявленных расхождений. В идеале к расхождениям могут добавиться еще и причины их появления (отказ от исполнения процедур процесса, осуществление изменений инфраструктуры минуя процесс и т.д.)

Так вот, с одной стороны проводить аудит CMDB должны люди, которые понимают в том, что они проверяют. Сложно, например, представить специалиста по приложениям, проверяющего корректность сведений о сетевом оборудовании.

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

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

Компания Pink Elephant ведёт занимательный проект — сбор статистических данных о реальных значениях процессных метрик, с целью, указанной в ITIL: "Organizations benchmark themselves against peers and seek to close gaps in capabilities" (организации сравнивают себя с другими, чтобы устранить имеющиеся недостатки в способностях). Принять участие в опросе может любая компания, а результаты периодически публикуются в блоге компании.

Сегодня появились обновлённые данные по процессу управления изменениями.

В опросе принимали участие организации из Америки и Европы, различного размера и отраслей.

Некоторые значения:

• Доля RFC выполненных с первого раза и по расписанию: медиана: 93%, среднее: 88%, минимум: <80%, максимум: >97%
• Количество запросов на изменение (RFC) в месяц: медиана: 525, среднее: 1791, минимум: <50, максимум: >5000
• Доля RFC, не отклонявшихся от процесса: медиана: 93%, среднее: 86%, минимум: <70%, максимум: >97%
• Доля срочных RFC: медиана: 7%, среднее: 9%, минимум: <1%, максимум: >15%
• Срок жизни RFC от регистрации до закрытия, в днях:  медиана: 22.5, среднее: 37.6, минимум: <3, максимум: >120

Более подробные данные и описание выборки читайте на сайте Pink Elephant.

А укладываются ли ваши значения в указанные Pink диапазоны? Поделитесь в комментариях!

Немногим ранее Дима опубликовал свои мысли по поводу измерения Incident Management’а и придумал интересную метрику (http://www.realitsm.ru/2011/12/measuring-incident-management/). Как уже говорилось, выросла она не на пустом месте, а в результате реальной потребности заказчика – в организации задумались о системе оценки персонала ИТ. Показатель по нарушению сроков инцидентов должен был войти в эту систему, и заказчика очень не устраивало то, что фактически ответственность за нарушение срока падала на последнюю рабочую группу, которая участвовала в обработке инцидента. А так как показатели должны были влиять на зарплату сотрудников, то можете себе представить, с какой аккуратностью подходили к созданию метрик. Наличие в системе одного такого «несправедливого» KPI может и революцию породить в рядах трудящихся . Метрика, предложенная Димой, хороша и проблему такого «шума» в KPI решает. Но вот незадача – чтобы такой метрикой пользоваться, надо откуда-то определенную информацию (о времени обработки каждой группой и переназначениях между группами) брать. Система автоматизации, которая используется у заказчика, такую информацию предоставить не может. Стали рассматривать варианты – можно, конечно попробовать в конфигурацию системы автоматизации определенные изменения внести, но это долго и дорого. Да и в скором времени ее планируют заменить другим продуктом. А информацию по нарушению сроков обработки инцидентов в систему измерений включать необходимо. Клинч . Думали-думали, и с менеджером процесса пришли к следующему решению: чтобы компенсировать «шум», просто снизили норматив по обработке . А вы как бы поступили? Может быть, мы прошли мимо какого-нибудь изящного решения? 

Мы продолжаем знакомить наших читателей с лучшей мировой периодикой по управлению ИТ-услугами. Международный itSMF форум издает журнал "At Your Service" (обзоры здесь и здесь), а вот у британского отделения Форума своё не менее интересное издание — serviceTALK.

Журнал оригинально свёрстан, наполнен иллюстрациями и классическим британским юмором, а содержание журнала актуально и для нас.

Главные статьи нового номера:

• Девять шагов к составлению осмысленной стратегии услуг — подход к написанию стратегии на основе семинаров.
• Из чего сделан хороший менеджер инцидентов, и как его удержать? — про настоящую ценность редкого вида.
• Дело о злом начальнике и культуре обслуживания — о том, как хорошие отношения, совместная работа сведут на нет вред от плохого начальника.
• Преподавание ITSM в высших учебных заведениях — преподаватели Университета Нортхемптона вспоминают об особенностях курсов по управлению ИТ-услугами для бакалавров и магистров.
• Готовы ли вы к новой роли, мистер CIO? — Действительно ли внутренняя служба ИТ больше не нужна в качестве бизнес-функции?

Рекомендуем этот выпуск к прочтению (необходим Adobe Flash Player). Статьи написаны реальными профессионалами, на основе личного опыта, простым английским языком.

В комментариях оставляйте ваши пожелания: если какая-либо из статей заслуживает подробного перевода на русский язык, мы с удовольствием разместим его на портале realitsm.ru!

Ура, наконец-то вышла моя статья про изменения в стандарте ISO 20000-1 2011 года, написанная ещё в октябре. Может быть, она придётся в тему, как другой поворот в дискуссии, начатой Костей в его заметке. Полный текст статьи, как обычно, доступен на нашем сайте по адресу http://www.cleverics.ru/ru/subject-field/hot-issues/changes-in-the-iso20000-1-2011.

Самой модной сетью общения профессионалов ITSM по всему миру на сегодняшний день является платформа микроблогов Twitter.com.

Конечно же, портал realitsm.ru также имеет своё представительство в Твиттер, и является одним из немногих микроблогов про управление ИТ на русском языке.

А вот на английском языке информации каждый день появляется значительно больше.

Вот только самое интересное за истекшую неделю:

vagrasala	Используя самые цензурные термины: изменения в сертификации специалистов после выхода #ITIL2011 можно было провести гораздо более тщательно!
theitskeptic	Мобильные телефоны стали как сигареты в прошлом: нужны, чтобы занять руки или просто круто выглядеть. http://t.co/3qVnKrbs
theitskeptic	Когда на Фейсбуке появится кнопка "Dislike"?
theitskeptic	RT @elliotross: Программисты типа "с-шашкой-наголо" стали главной проблемой жизненного цикла разработки ПО < подождите #Agile — вот тогда у них будет карт-бланш
fakeITIL	#НеЗаглядываяВВикипедию 73% людей старше 42 лет уже принимают #ITIL.
aalem	Когда происходят перемены, нужно забывать старые приёмы. 2012 год — отличный год для того, чтобы забыть ITIL.
theitskeptic	Эгегей! В поте лица своего работаю с #COBIT5
fakeITIL	Иногда мне кажется, что мои сисадмины ломают железки намеренно, чтобы было чем занять скучное время на работе #ITSM
HDI_Analyst	Вы новый менеджер поддержки? Нужны советы и подсказки? Пожалуйста: http://t.co/6zaW3bYE
theitilexperts	Управление временем: 6 способов повысить свою производительность: http://t.co/58YBoxfI
Joe_the_IT_guy	12 Важнейших привычек новых #IT сотрудников http://t.co/gLPLGcop
pinkerdavid	Как заставить людей следовать процессам? #НеудобныеВопросы #ITSM
pinkerdavid	Только что закончил читать статью "Состояние #ITIL", написанную @TheITSkeptic. Занимательно. http://t.co/Df8tx3CI #ITSM

А за кем в Твиттере (и других социальных сетях) следите вы? Поделитесь в комментариях!

Сегодня компания APMG сообщила о появлении нового уровня сертификации для менеджеров проектов — PRINCE2 Professional.

Напомним, что сейчас линейка сертификации PRINCE2, которой владеет APMG, состоит из двух последовательных экзаменов: Foundation (тест на знание методологии) и Practitioner (кейс, 9 вопросов, можно пользоваться книгой).

Никки Келли, менеджер по разработке продуктов в APMG и разработчик PRINCE2 Professional, говорит:

Уровень PRINCE2 Professional был создан по многочисленным просьбам обладателей сертификатов PRINCE2 Practitioner, которые хотели доказать свою способность успешно применять метод PRINCE2 на практике. Также мы отреагировали на мнение рынка о том, что организации нуждаются в сертифицированных по PRINCE2 менеджерах проектов, обладающих не просто знаниями, а компетенцией. Звание PRINCE2 Professional нужно тем, кто хочет продемонстрировать наличие практического опыта применения метода. Мы надеемся, что сертификация станет новым стандартом, к которому будут стремиться все профессиональные менеджеры проектов.

В пресс-релизе описана процедура получения звания PRINCE2 Professional:

• Для участия нужно успешно сдать экзамен PRINCE2 Practitioner (а до этого — PRINCE2 Foundation).
• Сертификация PRINCE2 Professional не подразумевает письменного экзамена.
• Группа кандидатов от 6 до 16 человек в течение двух с половиной дней работает в Оценочном центре, решая ряд задач в ролевой игре, основанной на кейсе (вымышленной организации).
• За тем, насколько успешно решаются задачи, следит ряд оценщиков, которые проверяют каждого кандидата по 19 параметрам: способность к бизнес-обоснованию, навыки межличностного общения, планирование "от результатов" и способность извлекать уроки из опыта и т.д...
• Решение о присвоении звания PRINCE2 Professional принимают оценщики, на основании своих наблюдений и интервью с каждым кандидатом.

Первая сессия PRINCE2 Professional начнётся в Англии 30 января. Подробную информацию об экзамене можно получить на сайте APMG International.

О доступности нового (и двух существующих) уровней сертификации специалистов PRINCE2 в России, пока, к сожалению, не сообщается. 

Помню в далёких девяностых на рынках многочисленные «предприниматели» предлагали гражданам свои услуги: «Золото, доллары куплю», «Доллары куплю / продам» и иже с ними. Помню одного гражданина, который пошёл существенно дальше других. Так одно время около Горбушки стояла девятка, в которой сидел спортивного вида мужчина, а на лобовом стекле была наклейка «Рассмотрю любые предложения». Вот она, культурная установка – всё для клиента. Прошли годы. Эта же установка никуда не делась, просто приобрела новые, более цивилизованные формы. И недавно на сайте одной компании я прочитал: «Основное направление деятельности компании Х – наиболее качественное удовлетворение покупательского спроса». Прекрасное направление деятельности

Под конец 2011 года в строю компаний, сертифицированных по стандарту систем управления услугами ISO/IEC 20000 случилось 2 пополнения:

BSI выпустила сертификат для компании ТБИнформ, свидетельствующий о соответствии системы управления услугами требованиям стандарта ISO/IEC 20000-1:2005 для "услуг технической поддержки системы управления сетями торговых представительств TBInform".

Bureau Veritas выпустила сертификат для компании РОСсвязьсистема, свидетельствующий о соответствии системы управления услугами требованиям стандарта ISO/IEC 20000-1:2005 для "услуг поддержки системы технологической отчётности на атомных электростанциях" и "услуг поддержки системы отчётности по уровням радиации на атомных электростанциях".

Поздравляем коллег с обретением сертификации, надеемся, что число и охват сертифицированных услуг у них будет только расти.

Предлагаем вам ознакомиться с полным реестром российских обладателей сертификатов ISO 20000. 

Около месяца назад Михаил писал о конкурсных процедурах при покупке консалтинговых услуг. Тогда вроде все довольно единодушно решили, что конкурсы-тендеры — не способ выбрать поставщика, а способ  (1) обосновать сделанный выбор перед спонсором и (2) заставить выбранного поставщика услуг снизить цену. 

И вот подтверждение этому выводу пришло, откуда я его не очень ждал. Дело в том, что клуб 4CIO выпустил в конце 2011 года чрезвычайно любопытную книгу — "Учебник 4CIO". Это во многом уникальный проект, призванный положить начало российской библиотеке передового опыта, формируемой CIO и признанными экспертами отрасли для CIO.

Выпущенная книга — первая версия, и предполагается выпуск обновлений. Важными особенностями учебника, на мой взгляд, являются следующие:

• многие главы написаны специально для учебника, а не скомпилированы из ранее выпущенных публикаций
• многие главы написаны — полностью или частично — действующими ИТ-руководителями и позволяют сформировать довольно интересный портрет современного российского CIO. 

Думаю, развёрнутую рецензию учебника стоит сделать предметом отдельной заметки, а пока — как иллюстрацию второй важной особенности и в продолжение поднятой Михаилом темы — приведу несколько цитат из главы, посвящённой управлению отношениями с поставщиками. 

"Выбирая поставщика, я прежде всего выбираю партнёра. Я ни разу не начинал тендер, не понимая, кто его выиграет. Безусловно, тендер нужен, чтобы довести до правильного уровня ожидания партнёра, прежде всего по деньгам. Но партнёра я всегда выбираю заранее. Выбор правильного партнёра — это важнейшее умение CIO, и его нельзя доверять случаю."

"Я не верю в конкурс, если сразу не понимаю, что будет на выходе. Это распространённая ошибка, когда ИТ-директор верит, что правильно построенный процесс обеспечит правильных партнёров, правильно написанные документы контракта и ТЗ. На практике так не бывает. (...) Опора только на правильные тендерные процедуры приводит к ошибочному результату."

Многие ИТ-директора применяют конкурс только как техническую процедуру, а весь выбор поставщика ведут заранее. Более того, именно в предварительной работе с потенциальным победителем тендера они видят залог будущего эффективного партнёрства. то есть, по сути, победитель тендера должен быть понятен CIO ещё до его начала, а сама процедура тендера может помочь детально согласовать ожидания обоих партнёров и повлиять лишь только на финансовую сторону взаимоотношений. 

Чрезвычайно интересная получилась книжка, очень познавательная. Я искренне рекомендую её всем, кто руководит ИТ-службой и всем, кто продаёт и оказывает им услуги. Первые могут узнать немало полезной информации из областей, за которые отвечают, а вторые — о людях, для которых работают.

Обращаюсь к сообществу — вы будете смеяться — с просьбой разъяснить терминологическую путаницу.

В стандарте ISO/IEC 20000-1:2011 появилось определение Internal group (внутренняя группа), следующего вида:

internal group — part of the service provider's organization that enters into a documented agreement with the service provider to contribute to the design, transition, delivery and improvement of a service or services

NOTE The internal group is outside the scope of the service provider's SMS

Мой перевод:

Внутренняя группа — часть организации поставщика услуг которая заключает документированное соглашение с поставщиком услуг, чтобы соодействовать проектированию, преобразованию, предоставлению и совершенствованию услуги или услуг.

ПРИМЕЧАНИЕ Внутренняя группа находится вне охвата системы управления услугами (СМС).

Это определение в тексте стандарта встречается 6 раз (вне глоссария):

• 2 раза в Governance of processes operated by other parties, где эта внутренняя группа приравнивается к внешним поставщикам услуг или компонентов.
• 1 раз в Design and transition of new or changed services, где внутренние группы являются источником новых требований к услугам, наряду с заказчиками и внешними поставщиками.
• 3 раза в требованиях к процессу Service Level Management, где стандарт требует заключения SLA с заказчиками, внешними поставщиками и внутренними группами.

Теперь из глоссария ITIL урожая того же года:

Соглашение операционного уровня (OLA) - Соглашение между поставщиком ИТ-услуг и другой частью той же организации. Это соглашение поддерживает поставщика ИТ-услуг в предоставлении ИТ-услуг заказчикам. Соглашение операционного уровня определяет предоставляемые товары или услуги и ответственность обеих сторон. Например, соглашения операционного уровня могут быть заключены:

• между поставщиком ИТ-услуг и департаментом снабжения о получении аппаратного обеспечения в согласованное время
• между службой поддержки пользователей и группой поддержки о разрешении инцидентов в согласованное время.

И там и там фигурирует некая "организация поставщика услуг", зажатая между заказчиком и внешними контрагентами.

Меня интересует ее "часть", которая упоминается в стандарте как internal group, а в ITIL — как субъект, с которым поставщик услуг заключает OLA.

ITIL даёт два варианта ответа: 

• это организация, частью которой является ИТ-служба (у нас распространена аббревиатура "ДИТ" или "УИТ")
• это группа внутри оргструктуры поставщика услуг (служба поддержки, группа системного администрирования, департамент разработки)

Стандарт же, насколько я могу трактовать вышеприведённое ПРИМЕЧАНИЕ, от второго варианта отказывается вовсе.

То есть аудитор, который будет сертифицировать СМС организации  на соответствие стандарту ISO 20000 (не важно — по версии 2005 или 2011 года), не будет рассматривать имеющиеся OLA как свидетельства СМС? 

То есть OLA в смысле договорённостей между различными командами\департаментами\отделами поставщика услуг — не нужны?!

То есть вспомогательных услуг не бывает?! (см. занимательную дискуссию у Скептика и, конечно же, у Дмитрия Исайченко — про равенство договаривающихся сторон)

То есть ITIL не прав?!.. дальше уж боюсь думать;)

Спасайте в комментариях! =)

Коллеги, спешу поделиться новостью — наша последняя крайняя книжка на прошедшей неделе была доставлена в издательство Livebook, которое помогает нам с распространением.

Это означает, что через неделю-другую её можно будет приобрести в Озоне, вместе с двумя другими нашими книгами — "Введение в реальный ITSM" и "Овладевая ITIL". Также книги можно найти в крупных книжных магазинах.

А пока можно посмотреть внутрь новой книги: