Real ITSM

COBIT. Старое, новое, лучшее

Олег Скрынник — Fri, 18 May 2012 07:20:24 +0000

Пятого июня состоится очередной семинар itSMF-Russia, в этот раз он будет посвящён COBIT. Так как я имею некоторое отношение к организации означенного мероприятия, то смею пригласить наших читателей и комментаторов принять в нём участие.

Из интересного: это первый семинар, который itSMF организует совместно с Московским отделением ISACA. Это означает — новые спикеры, новые участники семинара, информация из авторитетных источников.

Программа выступлений составлена следующим образом:

Сначала мы очень коротко напомним сами себе что такое itSMF и что такое ISACA.
Затем поговорим про COBIT вообще (конечно, уже с учётом новостей в пятой версии).
После этого можно рассмотреть подробнее что же изменилось/появилось в COBIT 5.
Никак невозможно обойтись без доклада практика, применяющего COBIT в своей организации.

Разумеется, семинар закончится бурной дискуссией. Готовьтесь.

Вообще перед семинаром ставятся две задачи: тем, кто не очень знает про COBIT — рассказать; тем, кто уже знает — рассказать про новый COBIT 5.

Приходите, будет интересно!

Регистрация открыта вчера, первый участник зарегистрировался через 9 секунд (!) после анонса. МИЭМ — большая "площадка", но и там число мест может быть ограничено.

Также по теме:

Роль менеджера управления ИТ-активами

Михаил Тобурдановский — Wed, 16 May 2012 05:53:05 +0000

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

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

Также по теме:

Вопрос из зала: когда и кому противопоказан сервисный подход?

Новостной поток — Tue, 15 May 2012 12:57:38 +0000

Вопрос задаёт наш постоянный читатель и комментатор Андрей Капустин:

Вопрос вынесен отдельно из обсуждения "Многоликие услуги"

В каких случаях сервисный подход не нужен или вредит бизнесу?

Для примера ситуации к обсуждению предлагаю свой проект:

крупный иностранный банк аутсорсит в российского подрядчика разработку и поддержку
заказчик декларирует, в том числе и через внутренние политики, свою высокую культуру ведения деятельности, в том числе и в связанных с автоматизацией областях
в проекте в котором я участвую как руководитель поддержки, интуитивно очевидно что уровень зрелости процессов в лучшем случае первый; при этом проблемы на мой взгляд порождены в далеко не последнюю очередь "весьма совковой" культуре процессов со стороны Бизнеса Заказчика, из-за чего подстраивающиеся (клиентоориентированные ) под заказчика аутсорсеры, ведут дела далеко не по хорошим практикам.

Мне сейчас Сервисный Подход кажется серебряной пулей, которая может единым образом устаканить как Бизнесовые так и IT взгляды на светлое будущее; хотел бы избавиться от этой иллюзии и вернуться в когорту поклонников IT sceptic'а.

В связи с чем хотелось бы знать в том числе: Как (под каким маркетинговым соусом) Вы (Ваша компания) продаете заказчикам (Бизнесу), что сервисный подход им нужен? То есть какие есть очевидные доводы, что без сервисного подхода Бизнес скорее проиграет чем выиграет?

Подозреваю, что затрагиваемая принципиальная тема "границ применимости подхода" должна разбираться в первоисточниках( ITIL, Cobit ?) или на курсах. Что бы порекомендовали почитать/посетить?

Также по теме:

Радуемся новостям в OMNITRACKER 9.3

Дмитрий Исайченко — Tue, 15 May 2012 05:00:56 +0000

При подготовке очередного планового релиза CleverENGINE (предыдущий вышел в январе 2012) мы прорабатывали вопрос планирования трудозатрат. Очень пригодилась новая функциональная возможность OMNITRACKER 9.3 отображать на план-графиках сведения о загрузке ресурсов. Получается симпатично (см. картинку), даёт наглядное представление о плановой загрузке при распределении новых задач. Теперь будет можно не только вести учёт фактических трудозатрат, но и планировать ресурсы.

Ну а что это будет за новый релиз и почему я считаю его серьёзным прорывом, узнаете чуть позже (я конечно имею ввиду в мае 2012, а не в 2013 году). Недолго уже осталось

Также по теме:

Новая бета-версия Tipu

Новостной поток — Mon, 14 May 2012 12:32:43 +0000

На днях Роб Ингланд отправил подписчикам сайта www.basicsm.com уведомление о том, что он завершил крупное обновление своего метода Tipu. Хотя версия и пятнадцатая по счету, столь существенная переработка случилась впервые:

Метод Tipu должен быть универсальным. Разделы про эксплуатацию и предоставление плохо подходили для не ИТ-организаций, поэтому эти разделы существенно переделаны, из-за чего ИТ-аудитории будет немного непривычно. Однако, представить себя в виде универсальной организации может оказаться полезным для ИТ-служб, ведь теперь им придется рассмотреть такие вопросы, как продажи, логистика и реклама. Даже сейчас в Tipu эти практики описаны довольно примитивно, и они будут детализированы глубже в будущем.

Одно из главных назначений Tipu — продемонстрировать сложность управления услугами. Слишком многие практики в методе являлись "сплавами" нескольких практик, что этому назначению противоречило, поэтому я разбил их на несколько. Диаграмма теперь не такая симпатичная и симметричная, но больше похожа на правду. Количество видов деятельности возросло с 51 до 81.

Скачать пятнадцатую версию Tipu можно здесь.

Обсудить изменения (или любой вопрос про управление услугами) можно на моем онлайн-форуме Tipu Talk:

Также по теме:

Допрос с пристрастием

Евгений Шилов — Mon, 14 May 2012 04:28:24 +0000

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

Я решил заодно и на портале упомянуть эту тему и важные моменты:

Нужно точно понимать, зачем проводится опрос, какие выводы предполагается сделать. Только так можно подобрать правильные вопросы и понять как затем обрабатывать ответы.
Вопросов не должно быть много (2-3 достаточно) иначе есть риск вообще не получить ответов или получить случайные ответы
Пользователя не надо заставлять что-то писать. Лучше если он может выбрать из имеющихся вариантов. Но при этом можно оставить возможность, что-то написать, если есть, что сказать.
Варианты должны быть однозначно отличимы друг от друга.
Возможны как вопросы, которые предполагают один ответ, так и вопросы, которые предполагают выбор нескольких вариантов.
Вопросы с готовыми ответами иногда являются провокационными (см. 2й вопрос в примере ниже). Такие вопросы с одной стороны указывают на то, что ИТ знает о своих проблемах и борется с ними, с другой стороны может побуждать пользователей оценивать ИТ по параметрам, о которых они не задумывались ранее. В итоге все зависит от цели вашего опроса.

Примеры таких вопросов:

Время решения вашего обращения соответствует вашим ожиданиям?
1. Ожидал(ла), что будет быстрее
2. Соответствует
3. Не ожидал(ла), что сделают так быстро
Укажите, общую оценку работы (можно выбрать несколько ответов):
1. Все прекрасно
2. Пришлось несколько раз повторять одно и то же
3. Решили не с первого раза
4. После решения стало хуже
5. Со мной грубо общались
Если вы хотите нам сообщить дополнительные сведения, то впишите их в следующем поле.

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

Также по теме:

9-й Российский IT Management Forum

Новостной поток — Sat, 12 May 2012 09:14:35 +0000

Издательство "Открытые системы" с 2004 года проводит регулярные мероприятия, посвящённые управлению ИТ-услугами и ИТ-менеджменту. В этом году событие приобрело название "Форум", его тематика сильно расширена.

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

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

Основные темы форума:

стратегическое руководство ИТ (IT Governance)
управление ИТ-активами: методы, инструменты, практика
ИТ-сервисы из «облаков»: предоставление и управление
BYOD: поддержка внутрикорпоративной мобильности
мобильный доступ к управленческим инструментам
ИТ-сервисы и самообслуживание пользователей
роль аналитических инструментов в стратегическом управлении ИТ, практика внедрения KPI и BSC
управление бизнес-процессами по методологии ITSM

Форум состоится 24 мая в гостинице Radisson-Славянская.

Дополнительная информация размещена на сайте Агентства корпоративных коммуникаций OSP-CON.

Также по теме:

Многоликие услуги: чего изволите?

Роман Журавлёв — Fri, 11 May 2012 15:12:25 +0000

Какая это, оказывается, бездонная тема — идентификация услуг. И как много зависит от принятого решения...

За последний месяц мы много об этом говорили — Дмитрий в своем вебинаре (да, теперь наш робот знает это слово!), хотя тема, казалось бы, была от определения услуг далека; я в заметке про структуру услуг и вчерашнем вебинаре; а уж какая развернулась дискуссия вокруг концепции построения каталога услуг!

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

Вот эта пара слов:

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

В общем, навязанные услуги — это плохо. И это справедливо не только для конкретных услуг, но и для всего сервисного подхода.

Также по теме:

Дуэль: ITIL против COBIT

Новостной поток — Fri, 11 May 2012 10:34:20 +0000

Во вчерашней статье Роб Ингланд (the IT Skeptic) системно обосновал свой взгляд на оба подхода.

Мне нравится ITIL, и я его часто использую. Но для меня остаётся загадкой, почему ITIL считается, по умолчанию, главным источником ~~лучших~~хороших, то есть общепринятых ~~процессов~~практик в ИТ? Некоторые считают, что это вообще единственный такой источник.

Мой источник хороших практик ИТ "по умолчанию" — это COBIT. Он побеждает ITIL одной левой.

Будучи консультантом, я в первую очередь обращаюсь за знаниями к COBIT. Именно в этот свод знаний я обращаюсь в первую очередь, когда мне нужно оценить, создать понятийную базу и список определений, обосновать или проаудировать. А когда мне нужно больше подробностей, или следует сослаться на авторитетный источник — я открываю ITIL.

В пользу COBIT Скептик приводит следующие аргументы:

Назначение. Руководство ИТ в COBIT против узкого управления ИТ-услугами в ITIL.
Охват. В ITIL V3 2007 описано всего 8 из 34 процессов COBIT 4.1. Вероятно, COBIT 5 увеличит отрыв.
Строгость изложения.
Отправная точка для оценки уровня зрелости.
Достоверность. У COBIT большая, но единая команда авторов, а владельцем выступает некоммерческая организация. У ITIL этого нет.
Доступность. COBIT несравнимо дешевле ITIL.
Новизна. Роб считает, что рынок еще недооценивает COBIT, но уже "наелся" ITIL.
Руководство. Слово Governance фигурирует только в ITIL Service Strategy, а в COBIT это понятие стало основой для построения методологии.

С другой стороны, в ITIL тоже есть положительные стороны, считает Роб, ведь это:

источник идей и мнений, пища для размышления,
огромное число читателей и пользователей, раскрученный бренд,
комплексная система сертификации специалистов (строительство которой было совсем недавно завершено),
система сертификации ПО (PinkVerify или Британского правительства)

Подробное обоснование точки зрения Скептика читайте в его блоге.

Также по теме:

Культ «Готово!»

Новостной поток — Sat, 05 May 2012 08:05:48 +0000

Как всегда перед длинными праздничными выходными, мы в редакции realitsm.ru решили отойти от основной тематики портала, и найти на просторах интернета что-нибудь полезное для вас. Перед выходными особенно интересно поговорить о работоспособности, правда?

Несколько лет назад, ~~хипстеры лентяи~~ блоггеры Бре Петтис и Кио Старк составили The Cult of Done Manifesto (Манифест культа "Готово!"). Он достаточно короткий:

Существует три стадии существования. Незнание, действие и завершённость.
Смиритесь: всё, что вы делаете — это "черновой вариант". Так проще завершить работу.
Этапа "редактирования" не существует.
Прикинуться, что вы знаете, что делаете — почти то же самое, что действитель знать, что вы делаете, поэтому просто примите как аксиому: "вы знаете, что делаете, даже если на самом деле не знаете", и сделайте это.
Полный бойкот прокрастинации. Если вы не начали реализовывать идею дольше недели, забудьте про неё.
Смысл завершённости не в том, чтобы закончить работать, а в завершении создания результатов.
Сделав что-то, можно про это забыть.
Смейтесь над совершенством. Оно скучно и мешает вам завершить результат.
Люди с чистыми руками неправы. Только труд подтверждает правоту.
Поражение тоже считается завершённостью. Совершайте ошибки.
Разрушение — один из вариантов завершения.
Если у вас есть идея и вы опубликовали её в интернете, считайте это подобием завершения.
"Готово!" — двигатель для "Больше!".

Удивительно, но спустя три года после создания, идеи манифеста не только живы но и процветают, например, в Facebook.

Всем удачных выходных!

Высшее образование по ITSM: почти реальность

Новостной поток — Fri, 04 May 2012 08:07:08 +0000

Британский университет The Open University и международный провайдер обучения Global Knowledge объявили о запуске совместной программы дополнительного высшего образования (Postgraduate Certificate) в области управления ИТ-услугами.

Обучение по программе "Postgraduate Certificate in Advanced Professional Practice (IT Service Management)" будет длиться один год. За этот срок студенты прослушают обучающие курсы по ITIL, а также некоторые курсы магистратуры бизнес-школы университета и факультета математики, вычислительной техники и технологии.

Бен Клейси, руководитель британского отделения itSMF:

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

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

Отметим, что аналогичные программы уже действуют в Нидерландах. Там учебная программа основана на ISM (Integrated Service Management) — голландском своде знаний, интегрирующем ITIL и ASM.

Подробности читайте в пресс-релизе Open University и на ITSM Portal.

Вопрос из зала: обсуждение ИТ-проектов

Новостной поток — Wed, 02 May 2012 10:14:38 +0000

Читатель, подписавшийся как Ritil ITинович, спрашивает:

Приветствую

На этом ресурсе много разной информации: обсуждений теорий и стандартов, небольших фрагментов проектов. Но полных реальных realitsm проектов здесь не нашел. Прочему бы не выложить несколько хорошо документированных проектов по ITSM, мониторингу, обсудить (экспертизу, так сказать, общественную), выбрать типовые решения, показать в них как теория сочетается с практикой и т.п. Хорошо бы и ценник показать, т.е. "что по чём». Вроде бы это должно входить в понятие: «realitsm». «Лучше один раз увидеть «realitsm» в реальных проектах, чем сто раз послушать». Уверен – эффект был бы куда выше.

Вообще, как правильно то документацию оформлять по itsm – проекту? Какова структура продукта «realitsm»?

Идею открытой библиотеки проектов (Ritil), в том числе и в itsm области, популяризирую на ritil.blogspot.com/2012/04/ritil.html

Какие Ваши мнения на сей счет?

Также по теме:

Смотрим на инциденты расширенными глазами

Константин Нарыжный — Wed, 02 May 2012 10:00:54 +0000

Хочу написать про еще одну технику управления рисками, незаслуженно забытую в книгах ITIL V3 2007 года, но восстановленную ("по чертежам" ITIL V2) в прошлогоднем обновлении.

Я говорю о расширенном жизненном цикле инцидента (the Expanded Incident Lifecycle). Это раздел в описании процесса управления доступностью (Availability Management), где предлагается разделять каждый инцидент (незапланированный перерыв в нормальном предоставлении ИТ-услуг) на обязательные последовательные этапы.

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

Позволю себе немного арифметики:

Момент закрытия – Момент возникновения =

Обнаружение + Диагностика + Ремонт + Восстановление + Возобновление

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

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

При первом прочтении меня больше всего заинтересовал в ITIL V3 пассаж про диагностику. Примерно такой:

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

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

Диагностика "сбой услуги" — "сбой компонента" должна осуществляться, чтобы определить, что именно следует чинить\менять для восстановления нормальной работы пользователей. Более глубокая диагностика, направленная на постоянное устранение причин сбоев уже должна осуществляться в управлении проблемами. Так на уровне определения процессов разделяется управление инцидентами и проблемами.

Но тут ITIL предлагает утопическую идею: а пусть в ходе диагностики, менеджер инцидентов "поднимет голову" и решит, стоит ли уже в ходе решения конкретного инцидента "один раз день потерять, но разобраться с такими инцидентами раз и навсегда".

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

Вопрос из зала: один сотрудник и множество сервисных объектов

Новостной поток — Wed, 02 May 2012 09:38:13 +0000

Сергей Посыльный спрашивает:

Работаем с системой построенной по третьему ITIL (BMC Remedy — не сочтите за рекламу).

В третьем ITILе по которому построена наша Remedy, обращения, инциденты, изменения разнесены по разным сущностям.

Мы говорим своим специалистам: закончил работу с Инцидентом залезай и бери новый (в зависимости от приоритета и крайнего срока).

Однако в нашей системе (да и презенташку MS видел – там та же проблема существует) для просмотра разных сущностей – разные «вьюшки».

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

Может быть подскажут уважаемые коллеги что с этим можно сделать или как выкручивались из этой ситуации?

Версия редакции портала realitsm.ru — на картинке. А что думаете вы?

Также по теме:

Новые ITIL® MALC и ITIL® Master: запуск сегодня

Новостной поток — Wed, 02 May 2012 06:12:04 +0000

Вчера компания APMG объявила о вступлении в силу обновлённой версии экзамена ITIL MALC (об обновлениях мы недавно писали). Кроме того, сегодня объявлено о запуске высшей ступени сертификационной линейки ITIL: ITIL Master.

Эта ступень сертификации представляет собой защиту письменной квалификационной работы, описывающей собственные проекты внедрения программ управления ИТ-услугами с использованием рекомендаций ITIL. Каждый соискатель ITIL Master должен будет продемонстрировать свой уникальный опыт, поэтому чёткой программы подготовки нет. Специального учебного курса тоже нет, потому что в каждом конкретном случае могут проверяться различные аспекты теории.

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

Шерон Тейлор, главный экзаменатор программы ITIL^, говорит:

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

Требования к соискателям ITIL Master очень простые:

Наличие сертификата ITIL Expert
Не менее пяти лет опыта работы в сфере ITSM в должности управленца или на высших ступенях консалтинга

Оценка влияния инцидента

Евгений Шилов — Sun, 29 Apr 2012 05:52:14 +0000

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

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

пользователи могут дать ответ
трактовка более-менее однозначна
вопросов не много (обычно 2-4)

Традиционную схему, которую часто приводят в пример, приходится усложнять. Базовая схема такова — есть два вопроса:

у вас одного не работает, или ваши коллеги тоже испытывают трудности?
у вас совсем не работает или недоступна только часть функционала?

На основании ответов есть 4 уровня влияния: самый простой случай — у одного сотрудника снижено качество ИТ-услуги (например, не работает часть функционала), самый тяжелый — у отдела или компании не доступна ИТ-услуга

В ней есть масса недостатков, вот пара примеров:

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

Усложнение схемы обычно связано с дополнением ее более четкими условиями. например:

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

Единственное, усложняя схему, приходится помнить о том, что пользоваться ей будут люди, и чтобы не получилось 3 правила с 45 исключениями, лучше 40 раз подумать

Всем удачных выходных!

Также по теме:

Слышать заказчика

Михаил Тобурдановский — Sat, 28 Apr 2012 08:31:54 +0000

Затеял я в квартире ремонт. Так получилось, что пришлось поработать с тремя бригадами рабочих, и это было очень похоже на выполнение консалтинговых проектов (я имею ввиду отношение к работе и результат). Одна бригада была далеко не профессиональной, и такое ощущение, что делали все в первый (ну или во второй) раз. Хотя начальник представил их как людей с большим опытом. Делали они все медленно и очень некачественно. Пришлось с ними расстаться. Вторая бригада делала качественно, но совсем нас не слышали. Когда я говорил, что хочу так-то и так-то – мне говорили, что так не делается, или что мы так не делаем, или что мы так не привыкли делать. Качество есть, но на выходе не совсем то, что ожидалось. Тоже расстались. А вот с третьей бригадой повезло – внимательно слушали, подсказывали, как можно сделать; а если им казалось, что я говорю ерунду – то аргументированно объясняли, почему так делать нежелательно и описывали возможные риски.

Это все к чему. Я в последнее время ловлю себя на том, что стал чаще соглашаться с решениями, которые в ходе проектирования предлагаются заказчиком. Естественно, это «соглашательство» — не по умолчанию. Если мне кажется, что заказчик ошибается – пытаюсь показать возможные риски и предложить другие решения. Понятно, что это вопрос баланса – в некоторых случаях приходится оказывать на заказчика давление, если решение действительно «не айс», а заказчик этого не понимает. Но поймать этот баланс ох как непросто .

P.S. Третья бригада молодцы-молодцы, но после получения аванса ушли в запой на пару дней . Р-р-р-р….

Также по теме:

Сервис-менеджмент в реальности

Новостной поток — Sat, 28 Apr 2012 08:07:26 +0000

Роб Ингланд (IT Skeptic) порадовал читателей блога The ITSM Review новой метафорой управления жизненным циклом ИТ-услуг.

На этот раз Роб "перевёл" основные понятия из своего метода Tipu на язык пассажирских и грузовых железнодорожных перевозок.

Виды деятельности в управлении услугами	Описание	Железнодорожный пример
Предоставление	Предоставление услуги пользователям	Еда и напитки, машинисты, стрелочники
Эксплуатация	Сопровождение инфраструктуры, которая обеспечивает предоставление услуги	Семафоры, ремонт путей, охрана
Поддержка	Реагирование и выполнение запросов пользователей	Продажа билетов, колл-центр, охранники и ремонтники
Каталогизация	Информирование о предоставляемых услугах	Расписания, вебсайты, буклеты
Отношения с заказчиками	Поддержка отношений с заказчиками	Менеджеры по работе с клиентами, продажи, PR
Измерение	Отслеживание и отчётность по сервисным метрикам	Пунктуальность, объем перевозок, прибыльность
Планирование	Предложение, выбор и разработка стратегии новых услуг, совершенствования имеющихся и вывода из эксплуатации устаревших	Маршруты, поезда, расписания, оптовые перевозки, специализированные вагоны (например, морозильники)
Проектирование	Как услуга будет работать и какая инфраструктура нужна	Разработка нового расписания и спецификация нового оборудования
Построение	Создание инфраструктуры, механизмов и процессов, необходимых для предоставления услуги	Заказ или выплавка новых рельсов, укладка, найм и обучение сотрудников, разработка информационных материалов
Внедрение	Развёртывание новой услуги в "продуктив"	Пуск новых подвижных составов, публикация нового или изменившегося расписания, начало работы новых сотрудников
Обеспечение качества	Защита организации, сотрудников, заказчиков и пользователей. Обеспечение уверенности в том, что услуга не наносит вреда, соответствует нормам и приносит прибыль	Программы безопасности на путях, реестр рисков, проверка билетов, аудиты финансов и качества
Совершенствование	Улучшение услуги: идентификация, планирование, управление мерами по совершенствованию результативности и рациональности	Программа качества, контроль затрат, регулярные ремонтные и профилактические мероприятия
Руководство	Задание направления, мониторинг и оценка того, как будет осуществляться ежедневное управление услугами	Корпоративное видение и цели, высокоуровневые политики, профили рисков и ежегодный отчёт

Подробности читайте в авторской колонке Роба.

Также по теме:

Впечатления от COBIT 5: неплохое описание процессов

Новостной поток — Fri, 27 Apr 2012 14:32:38 +0000

Первые впечатления от COBIT 5 продолжают поступать. На этот раз автор блога "Actionable ITSM" Девид Лоув, написал о самых ценных с его точки зрения разделах:

Описание и рекомендации по видам деятельности в процессах:

Процесс DSS02 в COBIT 5 "Управление сервисными запросами и инцидентами" примерно совпадает с процессом управления инцидентами и процессом управления сервисными запросами (точное название: Request Fulfillment — прим. ред.). Сам процесс DSS02 разбит на семь управленческих практик. А внутри каждой практики описаны виды деятельности, которые можно исполнять.

Метрики:

Для каждого процесса COBIT 5 приводит несколько связанных с ИТ целей, достижению которых этот процесс способствует. Рядом с каждой целью приведён список рекомендуемых метрик достижения целей. Коенчно же, в каждой организации свой набор данных, поэтому предлагаемые метрики придётся подстраивать под себя. Но взять эти за основу можно.

Матрица RACI

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

Подробности читайте в статье Девида

Также по теме:

Управление изменениями и релизами: один или два процесса

Дмитрий Исайченко — Fri, 27 Apr 2012 11:08:05 +0000

Мы-таки провели этот вебинар (давно уже собирались). Вопрос поднимался неоднократно, системного ответа не было. Теперь, как мне кажется, есть: http://www.cleverics.ru/ru/subject-field/webinars#past (прокрутить вниз до вебинара от 26.04.2012). Если есть вопросы – велкам, обсудим. Специально для этого и создал этот пост.

Также по теме:

Осторожнее с инновациями!

Новостной поток — Thu, 26 Apr 2012 11:17:35 +0000

Роб Ингланд (IT Skeptic) написал статью про ~~модернизацию~~ инновации. Скептическую, конечно же:

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

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

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

Глядя в будущее, легко забыть о работающем настоящем. Попытки внедрять инновации могут оказать просто разрушительное влияние на то, что у нас есть сегодня. Сила человеческого общества заключается в способности передавать знания из поколения в поколение. Те, кто не учит уроков истории, обречены их повторять.

Хорошее проектирование часто означает переработку старого, и под "хорошим" я имею в виду соответствие бизнес-требованиям (спрос\риск\трудности). Иногда, самым верным решением будет возвращение к старой практике. Если говорить о результативности и рациональности, из прошлого можно извлечь столько же пользы, сколько из яркого, ненадёжного будущего.

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

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

Все остальные: идите, работайте. И не надо пялиться на горизонт — нам нужно поддерживать бизнес. Вы похожи на ватагу детей, которая выбежала с криками из ворот увидев яркую и шумную машину, проезжающую мимо. Если нам и нужно Облако, об этом позаботятся ИТ-директор и архитекторы. Вам сообщат о решении. Любите играть с классными игрушками? Надо было лучше учиться в школе.

Ну как вам? Не слишком ли критичен Скептик? Поделитесь в комментариях.

COBIT5: первые впечатления

Роман Журавлёв — Wed, 25 Apr 2012 12:56:04 +0000

...пока не мои. Все, кто следит за развитием сводов знаний и стандартов в ИТ-отрасли, провели две недели, прошедшие с 10 апреля, за чтением COBIT5. Ну или хотели бы их так провести, имей они такую возможность. Вот постоянный автор itsmportal.com Geoff Harmer делится некоторыми впечатлениями от знакомства с обновленным COBIT5, который, кстати, теперь называется A Business Framework for the Governance and Management of Enterprise IT. Пока и мы не разберемся в своих впечатлениях, уверенно перевести это на русский язык я не берусь. Вот некоторые наблюдения из тех, которыми поделился Geoff (полная версия — на ITSMPortal.com). Ну и мои краткие комментарии.

Corporate governance или Enterprise governance? До COBIT5 эта область называлась в литературе corporate governance. Теперь использовано слово enterprise. Кроме отхода от сложившейся практики, смущают различия в понимании этих терминов в американской и европейской деловой культуре. Джефф, во-первых, считает рассматриваемые слова синонимами и, во-вторых, предполагает, что используя термин enterprise, авторы хотели подчеркнуть применимость COBIT5 не только в коммерческих организациях, но и, например, госструктурах.

Мне кажется адекватным использование в русском варианте слова "предприятие" -РЖ

Governance и/или Management? Один из принципов COBIT5 (а там теперь есть 5 принципов) говорит о "separation of governance and management". Джефф считает эту формулировку неудачной — разделение, по его мнению, подразумевает "разъехались и не общаемся". В то время как governance и management вроде бы должны поддерживать отношения. Предлагается такая формулировка: "governance and management are integrated but distinct", что-то вроде "мы перестали быть супругами, но остались родными людьми".

Нам бы их заботы. Мы тут пока никак не договоримся о переводе самих goverrnance и management. Например, Российское издание COBIT 4.1 переводит governance как "корпоративное управление". Боюсь, в COBIT5 этот номер не сработает — если только не переводить management как "руководство" или "менеджмент". Лично мне нравится комбинация из "руководства" (governance) и "управления" (management), хоть этимологически дело обстоит ровно наоборот.

Домены и процессы. Их теперь 5 и 37 соответственно. Они неудобно (мне; кому-то, наверное, нравится — РЖ) называются трехбуквенными аббревиатурами с двузначными номерами. Например, домен DS (Deliver and Support) теперь называется DSS (Deliver, Service and Support), а, например, управление инцидентами — DSS02 Manage Service requests and incidents. Примечательно, что примерно треть процессов описывает лучшие практики из других подходов, исполняя заявленную роль "интегрирующего подхода", призванного собрать под одной обложкой все самое свежее и полезное. Что не может не радовать.

Действительно, даже поверхностное знакомство с новой процессной моделью оставляет весьма благоприятное впечатление. И Manage Service requests and incidents — гораздо лучше, чем прежнее Manage Service Desk and incidents : )

Enablers. Их семь, три из них (5-7, выделены курсивом) — ресурсы:

Принципы, политики, подходы (не назвать ли их "Три П" ? — РЖ)
Процессы
Организационные структуры
Культура, этика, поведение
Информация
Услуги, инфраструктура и приложения
Люди, навыки и компетенции

Из них на данный момент детально (отдельной публикацией о 230 страницах) рассмотрены только процессы. Остальное лишь обозначено в общем описании подхода.

Enablers — "факторы, совместно и по отдельности влияющие на работу чего-либо". То есть буквально "факторы влияния". Есть у кого-нибудь другие варианты перевода?

Каскад целей (Цели бизнеса — Цели ИТ — Цели ИТ-процессов), представленный в COBIT 4.1 в приложении, стал важнейшей частью COBIT5. Еще он стал сложнее (четыре уровня вместо трех). Теперь выше целей бизнеса появились 22 stakeholder needs (еще одна задачка для переводчиков — РЖ), отчего-то сформулированные в форме вопросов. Джефф полагает, что этот список пришел к нам из известной публикации "Board Briefing on IT Governance 2nd Edition", где это были именно вопросы, — пришел и практически без изменений встал на вершину каскада.

Каскад целей — действительно полезная игрушка, не зря ему теперь уделили столько места. В Российском издании это приложение отчего-то отсутствует, а жаль. Главное — не воспринимать описанные там цели как единственно верные, не использовать "в лоб", хотя соблазн, конечно, велик. Из всех известных мне инструментов COBIT этот более всего похож на серебряную пулю.

Вывод, который делает Джефф из первого близкого знакомства с COBIT5, оптимистичен:

В целом, COBIT 5, похоже, стремительно становится de facto стандартом для бизнес-руководства и управления ИТ на предприятиях и разумеется, что все прочие подходы и стандарты будут его интегральной частью.

Я пока выводов не делаю, мне пока просто очень интересно.

PS. Чуть не забыл. С учетом сказанного предлагаю считать COBIT5 "Бизнес-методологией руководства и управления информационными технологиями на предприятии".

Также по теме:

Вопрос из зала про каталог услуг: что улучшить?

Новостной поток — Fri, 20 Apr 2012 09:21:15 +0000

Максим спрашивает:

Здравствуйте. Дано: крупная компания для которой ИТ — непрофильная деятельность. Внутри есть Департамент ИТ, который осуществляет ИТ-поддержку (как в части эксплуатации, так и в части развития (доработки) информационных систем). Необходимо сделать каталог услуг. Я разработал концепцию построения каталога, в которой определил термины, взаимосвязи понятий и рассмотрел примеры. Документ небольшой — 4 неполных страницы. Очень хочется услышать критику или рекомендации по развитию\трансформации концепции. Заранее спасибо.

С разрешения автора, публикуем этот документ.

Ваши рекомендации, коллеги?

Также по теме:

Семь преимуществ KEDB

Новостной поток — Thu, 19 Apr 2012 14:33:50 +0000

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

Известный колумнист Симон Моррис написал большую статью про эту чудесную базу, и, в частности, привёл ключевые преимущества от её использования:

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

Подробности читайте в статье на theitsmreview.com.

Также по теме:

Управление ИТ как государственное дело?

Новостной поток — Wed, 18 Apr 2012 06:20:51 +0000

Российских новостей в нашем потоке немного: об эффективности ИТ мало пишут и говорят, "потому что работать надо". Но сегодня мы не могли не заметить выступления чиновника аппарата Правительства РФ. Похоже, скоро заинтересованных прибавится.

На прошедшей в апреле конференции CNews "ИКТ в госсекторе: электронное правительство неизбежно", руководитель Департамента ИТ и связи Правительства РФ Алексей Попов выступил с рядом занимательных идей, касающихся развития ИТ в государственном управлении в России.

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

В ближайшем будущем планируется извлекать любую информацию, необходимую для принятия федеральными чиновниками управленческих решений, только из центрального хранилища, а не прямыми запросами к владельцу информации, как было раньше. При этом отмечается, что единого стандарта информационных систем для всех субъектов РФ не появится. Регионы и федеральные органы власти будут самостоятельно отвечать за интеграцию обмена данными с центром (ГАС "Управление").

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

На уровне председателя Правительства решен вопрос о том, что в каждом ведомстве и субъекте ответственные за ИТ в ранге замруководителя должны быть аттестованы. Будет как в случае с законом о госзакупках (94-ФЗ): не прошедшие такую аттестацию не смогут заниматься информатизацией. Если человек не понимает, что такое проектный подход, ITIL, значит, он не должен руководить ИТ-подразделением: слишком большие деньги на это тратятся, чтобы рисковать.

Приятные глазу аббревиатуры типа "ФОИВ", "СМЭВ" и "ЕМИСС", полный текст новости и видео выступления смотрите на Cnews.ru.

Как вы оцениваете перспективу этого решения уходящего премьера? Не забудет ли о нём новый? Поделитесь в комментариях!

ITIL от Чака Норриса

Новостной поток — Tue, 17 Apr 2012 11:36:34 +0000

Американский блоггер Майкл Слабодник (@itilandme) в своём блоге описал идеальный мир управления ИТ. Ну тот, в котором единственным автором ITIL является Чак Норрис:

Процесса управления проблемами нет вообще. Ведь у Чака Норриса нет проблем.
Требования к квалификации ITIL Master уже определены и опубликованы: если вы не Чак Норрис — даже не надейтесь.
Печатать пять книг не приходится: все знания мгновенно доносятся до слушателя знаменитым ударом с разворота.
Постоянное совершенствование услуг не нужно: под управлением Чака Норриса услуги улучшают себя сами.
Раздел про другие своды знаний и лучших практик тоже отсутствует: всё, что написано Чаком Норрисом и так идеально.
26 процессов будут объединены в один: Управление Ударом Чака Норриса.
Обновлять ITIL не требуется: Чак Норрис делает всё верно с первого раза.
95% компаний смогли внедрить CMDB (на самом деле 100%, но Чак Норрис великодушно оставил 5% авторам других сводов знаний, чтобы у них была иллюзия своей ниши на рынке).
Функций всего две: Последователи Чака Норриса, и те, кто пытается вспомнить своё имя после встречи с ним.
Все, кто заслужил звание ITIL Expert должны носить черный пояс и пробивать доски кулаками, чтобы подтвердить свою сертификацию. Бумажка в рамке на стене — не для Чака Норриса.

Другие характеристики правильного ITIL можно найти в блоге Майкла.

Пора перезагрузить управление услугами

Новостной поток — Mon, 16 Apr 2012 12:04:07 +0000

Озаглавленную так статью про управление ИТ-услугами написал Иан Клейтон. На этот раз, Иан предлагает всем консультантам и практикам ITSM отказаться на время от "ИТ" и вернуться к старому доброму традиционному управлению услугами.

Вспоминая о публикациях Ричарда Нормана и Теодора Левитта (одними из первых формализовавшие стратегию управления услугами), Иан предлагает поставщикам ИТ-услуг вспомнить об универсальных принципах управления услугами, то есть выйти за традиционные рамки "ИТ как форма дополнительной ценности для заказчика".

Если остановиться на структурировании деятельности ИТ только для того, чтобы предоставлять заказчику стабильный уровень ценности, ИТ-услуги превратятся просто в commodity (рядовой потребительский товар), и заказчики не смогут различить предложения разных поставщиков.

А значит, каждый поставщик должен принимать во внимание не только потребности в ИТ, но "потребительский опыт" своих заказчиков.

Иан активно ссылается на USMBOK, и на понятия лежащие в основе этого свода знаний:

Service Encounter (момент потребления услуги заказчиком, или его общения с сервисной организацией)
Expectation (ожидания)
Experince (опыт)
Emotional genie (эмоциональный аспект)

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

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

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

Полностью эту статью читайте в блоге Иана Клейтона.

Outside-in thinking, не так ли?

Также по теме:

Героизм в ITIL V3: борьба с инцидентами

Константин Нарыжный — Fri, 13 Apr 2012 11:00:33 +0000

На недавнем курсе слушатели, работающие в крупном системном интеграторе, смогли найти в ITIL V3 очередное противоречие. Их находкой хочу поделиться с вами. Итак: два понятия.

Первое – это SLA: соглашение между поставщиком ИТ-услуг и заказчиком. Соглашение об уровне услуг описывает ИТ-услугу, документирует целевые показатели уровня услуги, указывает зоны ответственности сторон – поставщика ИТ-услуг и заказчика.

А второе – это часть определения инцидента из книги Service Operation: …Сбой конфигурационной единицы, который еще не повлиял на услугу, также является инцидентом, как, например, сбой одного диска из массива зеркалирования… (отличное слово, кстати: женщины перед походом в театр зеркалируют часами).

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

И вдруг, ITIL, всё про SLA хорошо объяснив и подтвердив практический опыт, огорошил их: несмотря на то, что устранение инцидентов может предоставляться дискретно (например, только днём, с 9 до 18), инцидент, обнаруженный в «нерабочее» время, следует устранять немедленно. Или, если взять "зеркалирование" — то придётся восстанавливать диск за свой счёт, а пользователи и заказчик вообще ничего об этом не узнают.

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

«А город подумал – ученья идут...». Но геройствовать, вслед за лучшими практиками, мои слушатели не хотят.

Как быть? Кто прав?

Также по теме:

Вопрос из зала: Обходное решение проблемы или типовое решение инцидента?

Новостной поток — Thu, 12 Apr 2012 11:40:28 +0000

Владимир спрашивает:

И снова о проблемах... в продолжении последнего семинара Евгения Шилова.

Утрировано рассмотрим ситуацию с ошибкой в книге ITILv3 2007.

В Книге в двух местах дано разное определение термина проблема. Из-за этого на экзаменах люди допускают ошибки и не набирают соответствующий бал.

Проблемой в данном случае является ошибка в книге.

Инцидентом низкий бал на экзамене.

Решением инцидента является апелляция, результатов экзамена.

Обходным решением проблемы является исключение из экзамена вопросов связанных с ошибкой.

Структурным решением является переиздание книг.

Вопросы:

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

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

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

Если под обходным решением предлагается типовой механизм решения инцидентов при их появлении... для меня это типовое решение инцидента, а не обходное решение проблемы...

При этом проблем менеджмент может предлагать как обходные решения проблем, так и типовые решения инцидентов.

Хотелось бы услышать вашу точку зрения по данному вопросу Может я где-то запутался

Также по теме:

Каких ИТ-специалистов найти труднее всего?

Новостной поток — Thu, 12 Apr 2012 09:47:11 +0000

Джастин Джеймс в блоге TechRepublic опубликовал десять вакансий в ИТ, заполнить которые труднее всего.

ИТ-тренер: уникальный набор навыков и редкий для большинства ИТ-шников разъездной характер работы — делают поиск кандидатов на эту вакансию самым сложным для кадровиков.
Менеджер проектов: многие компании вносят в формальные требования к кандидатам сертификацию PMP, и становятся заложниками собственных высоких стандартов: ведь обладателей сертификатов PMI довольно мало и они дорого просят за свой высокий статус.
ИТ-директор/Технический директор/CIO и т.д.: как и от тренера, от лидера ИТ-команды требуется нечто большее, чем технические знания.
Сотрудник Sevice Desk: ведь те кандидаты, которых действительно хочется нанять на такую стрессовую работу, хотят получать гораздо больше, чем вы можете им предложить.
Узкоспециализированные разработчики ПО: ведь их так мало на рынке (а хороших — еще меньше).
Инженер-продавец: хитрая комбинация глубоких технических знаний и умения продать товар потенциальному клиенту.
Технический писатель: разбирается в технологиях и владеет языком достаточно хорошо, чтобы писать понятные пользователям документы.
Евангелист: кто-то, кто будет продвигать продукты и услуги компании на рынке, постоянно поддерживая положительное мнение о них в широких профессиональных кругах. Актуальные знания технологий должны сочетаться в таком специалисте с действительно твёрдой верой в них. И, как и в случае с тренерами и продавцами — готовностью часто и много путешествовать.
ИТ-блоггер: удивительно, как мало людей способных создавать качественный контент в формате статей с регулярной интенсивностью, год за годом.
Программисты для устаревших платформ: единственный способ заманить сотрудника на разгребание кучи старинного недокументированного кода — это обратиться к недавним студентам со словами "наличие опыта работы не обязательно" и "требуется готовность учиться".

А какие должности в ИТ в этот список добавили бы вы? Поделитесь опытом подбора ИТ-персонала в комментариях!

Также по теме:

Соединение стандартов управления активами

Михаил Тобурдановский — Thu, 12 Apr 2012 08:00:37 +0000

Недавно наткнулся на интересную статью Дэвида Биккета (David Bicket) о соединении стандартов ISO 5500х (управление активами) и ISO/IEC 19770-1 (SAM). Дэвид – уполномоченное лицо и член рабочей группы ISO SAM, принимал участи в разработке стандарта ISO/IEC 19770-1, а с 2010 года – и член комитета ISO PC251. Этот комитет отвечает за разработку международного стандарта по управлению активами (заметьте, активами без приставки «ИТ» ). Стандарты ISO 5500х и ISO/IEC 19770-1 в настоящее время переписываются в соответствии с некими требованиями к описанию стандартов систем управления. Такой подход позволяет использовать стандартизированные принципы описания, использование общей терминологии, некоторых общих пунктов и т.д.

Предыдущая версия стандартов ISO 5500х не учитывала национальную и отраслевую специфику управления активами, а также специфику управления ИТ-активами. Результат – новая версия стандарта (пока в черновике) которая имеет «зонтик» для покрытия всех видов активов: « ISO 5500X в основном предназначен для управления физическими активами, но это не ограничивает применение принципов управления к другим типам активов."

Дэвид призывает соединить стандарт ISO/IEC 19770-1 с ISO 5500х, чтобы не иметь два перекрещивающихся стандарта с разными фокусами управления.

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

Мир меняется, и сейчас «физики» сталкиваются с «умными» активами, которые имеют на борту ПО; в свою очередь, ПО неотделимо от физических активов. Поэтому Дэвид активно призывает членов IAITAM читать черновики ISO 5500х, ISO 19770-1 и давать замечания и предложения к новой версии ISO 19770-1. Это позволит уже на ранней стадии разработки гарантированно «вписать» SAM в международный стандарт управления активами. Посмотрим, что из этого выйдет.

Также по теме:

Жажда проблем

Евгений Шилов — Wed, 11 Apr 2012 17:33:57 +0000

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

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

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

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

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

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

Также по теме:

Еще пара слов о структуре ИТ-услуг

Роман Журавлёв — Tue, 10 Apr 2012 18:24:46 +0000

Удивительно, как иногда простые идеи долго доходят до сознания.
Д. Исайченко

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

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

Оказание услуги – это всегда деятельность поставщика услуг и иногда предоставляемые заказчику ресурсы. Но для заказчика это совсем не обязательно так. Иногда заказчик отождествляет услугу с ресурсами, иногда – с деятельностью поставщика, иногда (редко) осознает это разделение составляющих услуги. Происходит это оттого, что заказчик уделяет внимание в первую очередь тем элементам услуги, которые непосредственно формируют то, что ITIL называет «полезностью» (utility), и гораздо реже – тем, которые должны обеспечивать так называемую «гарантию» (warranty), то есть уверенность в том, что полезность действительно будет ему предоставлена в оговоренных условиях. Из довольно внушительного списка параметров качества, применимых к любым услугам, заказчики обычно обращают внимание на три: функциональность, доступность и цену. А эту самую полезность могут формировать:

предоставляемые заказчику ресурсы (например, размещение в гостинице, прокат автомобиля, предоставление доступа в интернет, предоставление средств автоматизации бизнес-деятельности…);
выполняемая сотрудниками поставщика услуг деятельность (доставка грузов и корреспонденции, уборка помещений, консалтинг, обучение (как передача знаний), анализ информации, моделирование бизнес-процессов…);
сочетание деятельности и ресурсов (обучение как передача умений и навыков обращения с ресурсами – музыкальными инструментами, механизмами, компьютерной техникой…, такси и другие транспортные услуги, реализация бизнес-процессов заказчика).

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

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

Такой "ресурсный" характер ИТ-услуг важно учитывать не только при обосновании нересурсных ИТ-проектов, но и, например, при формировании каталога услуг. Наукообразные формулировки вроде «Услуга обеспечения доступа к ресурсам сети Интернет», конечно, подчеркивают важность работы ИТ-службы, но не добавляют ясности в отношения этой службы и заказчиков. Заказчики гораздо лучше поймут каталог услуг, в котором будет написано просто «Интернет», ведь именно интернета они ждут на выходе, а вовсе не "деятельности по обеспечению..."

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

Также по теме:

Опубликован COBIT5

Новостной поток — Tue, 10 Apr 2012 06:46:39 +0000

Как и сообщалось ранее, датой публикации COBIT5 стало 10 апреля 2012 года. То есть сегодня!

Новый COBIT — он такой же, как раньше, но совсем другой: авторы называют этот релиз "самым значительным эволюционным шагом за шестнадцатилетнюю историю подхода".

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

Также по теме:

Разрушители легенд: документы SLM

Дмитрий Исайченко — Mon, 09 Apr 2012 09:42:36 +0000

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

Начнём с технических услуг и OLA. По-серьёзному это конечно разговор не на 5 минут. Но если быть кратким, наличие каталога технических услуг и OLA почти всегда недооценивается по последствиям в виде влияния на другие процессы, отношения между подразделениями и даже на оргструктуру. Такая практика управления применима далеко не ко всем компаниям. То есть уточню: сервисный подход вообще применим лишь к небольшому количеству компаний (из тех, что известны мне), и только к очень небольшой доле из этого маленького количества компаний применима практика ведения каталога технических услуг и OLA. О том, что с этим надо быть осторожнее, как-то давно (2006?) писал Pink elephant, а относительно недавно (2011) – IT Skeptic. Подтверждает это и наша проектная практика.

Теперь про каталог бизнес-услуг и SLA. Здесь тоже нет единственно верной дороги. Сам по себе каталог услуг с различными уровнями обслуживания по каждой услуге фактически востребован только в сценариях массового обслуживания – когда у одной услуги может быть множество заказчиков, каждый – на своём уровне. В случае внутреннего ИТ-подразделения довольно часто мы имеем одного заказчика, в качестве которого выступает основной бизнес (в виде одного или нескольких подразделений). Да и технические возможности по варьированию уровня услуги также ограничены (поскольку используется единая инфраструктура). В этом случае отделение бизнес-услуг от SLA может быть излишним. Фактически сам каталог услуг становится «каталогом SLA» (а приложением к SLA идут внешние спецификации услуг).

Поэтому стандартное восприятие продуктов (outcomes) SLM как «два каталога услуг + SLA + OLA» имеет довольно ограниченное применение. Это вдвойне важно осознавать в случае, когда сам процесс управления уровнем услуг в основном воспринимается как процесс, который готовит и актуализирует эти документы. Хотя, на мой взгляд, это не составляет и половины содержания SLM как процесса

«Контора пишет!», как говорил один известный персонаж.

Также по теме:

Вопрос из зала: С чего начать изучение ITSM/ITIL?

Новостной поток — Fri, 06 Apr 2012 05:13:05 +0000

Рубрика "Вопрос из зала" в последнее время приобрела заметную популярность, чему мы очень рады.

Анатолий спрашивает:

Добрый день, коллеги!

Обращаюсь к вам за советом.

Работаю в среднего размера российском банке. Работали мы во многом по-старинке, сейчас же пытаемся выйти на современные методы управления IT. За 5 лет дорос до руководителя сопровождения ПО и сейчас всем этим активно занимаюсь, в частности составляем SLA и пр. Но опыта работы с ITSM/ITIL нет.

Посоветуйте, с чего начать, чтобы быть на "ты" с ITSM /ITIL? Что почитать сперва, имеет ли смысл идти на обучение или нет (курсы? какие?). Информации много, не хочется заблудиться в ней).

Буду признателен за советы.

Также по теме:

Обновлён официальный учебник ITIL Foundation

Новостной поток — Thu, 05 Apr 2012 14:00:49 +0000

Вчера на сайте APMG открылась продажа PDF-версии книги "Passing your ITIL Foundation exam — based on ITIL 2011 syllabus".

Рекомендации ITIL V3 2011 будут сжаты в 212 страниц, на которых будет описано "всё, что нужно для подготовки к сдаче экзамена", и еще немного больше:

Выдуманный кейс, на котором реализуется программа управления услугами
Mind Maps и прочие сжатые формы изложения материала
73 пробных экзаменационных вопроса, "которых нет нигде больше", с объяснением правильных ответов

Купить книгу за £22 можно прямо на сайте APMG. PDF-файлы защищены от копирования технологией ADOBE Adobe Digital Editions.

Также по теме:

EXIN: ИТ-экзамены можно сдавать, не вставая с дивана

Новостной поток — Wed, 04 Apr 2012 07:33:23 +0000

Экзаменационный институт EXIN, представляющий линейку экзаменов ITIL и ISO 20000 ITSM в России и по всему миру, объявил о запуске системы сертификационных испытаний через Интернет.

Система получила название Exams Online. Она создана на базе безопасного решения от Software Secure. С её помощью, ИТ-профессионалы смогут заказывать, оплачивать и сдавать экзамены не выходя из дома.

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

Микель ван дер Ланде, исполнительный директор EXIN:

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

Со 2 апреля система Exams Online работает в США. Авторы обещают развернуть её по всему миру в ближайшее время.

Как скажется эта инновация на качестве сертификации? Поможет ли это новшество популяризации ITSM в России и в СНГ? Поделитесь вашим мнением в комментариях!

Также по теме:

15 новых правил игры для ИТ

Новостной поток — Mon, 02 Apr 2012 07:27:27 +0000

Крис Мёрфи, колумнист издания informationweek.com, составил список из 15 новых законов, которым должно следовать современное ИТ-подразделение, способное поддерживать своих заказчиков эффективнее чем любые конкуренты и, одновременно, гибко и быстро использовать технологические инновации.

Относиться к планшетным компьютерам как к рабочим лошадкам а не как к пони в зоопарке.
Использовать видео, мгновенные сообщения и голосовую связь, чтобы совершенствовать совместную работу (collaboration) в организации.
Освоиться в социальных технологиях.
Подружитесь с CMO (директором по маркетингу) — уметь демонстрировать, что ИТ уже не является центром затрат, а поддерживает достижение целей бизнеса.
Применять мобильные технологии, чтобы повысить удовлетворённость клиентов.
Возрождать подразделение собственных разработчиков ПО.
Обновлять навыки, в соответствии с духом времени. Это правило для ИТ-директоров, до сих пор считающих, что знание технологий — важнее, чем понимание бизнеса заказчиков.
Относиться к ЦОД как к результату, а не как к "зданию".
Подготовить инфраструктуру к использованию возможностей "облака".
Приготовиться к тому что пользователи "принесут на работу своё собственное облако" (ссылка на модный BOYD)
Проектировать безопасность не только сетевого периметра, но и данных.
Разрабатывать инструменты анализа, а не статичные отчёты.
Готовиться к совершенствованию, а не к совершенству.
Проводить ИТ-проекты не за годы, а за месяцы или недели.
Узнать того, кто покупает результат вашего труда, и что является важным именно для него.

Подробные комментарии и примеры из практики автора, читайте в его статье.

А какие правила актуальны для вас?

Техподдержка против ИТ-проектов?

Константин Нарыжный — Mon, 02 Apr 2012 05:34:36 +0000

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

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

В жизни такой риск иллюстрировался, например, «незаводским Китаем»: телефоны, похожие на iPhone, но с телескопической антенной, продающиеся и по сей день. У них крайне невысокая цена, а внешне от прототипа они почти не отличаются. И в них даже можно вставить симку и она будет работать.

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

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

Но тут опытом поделился слушатель, работающий на крупного внешнего поставщика ИТ-услуг. Его опыт таков: эксплуатационщики не горят желанием работать на проекте!

У нас полно своей работы, а тут еще вы что-то готовите! Нет ресурсов! Ничего не хотим знать до того, как внедрите! А потом уже скрепя сердце начнём разбираться, чего вы там наваяли!

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