Портал №1 по управлению цифровыми
и информационными технологиями

Business Agility, DevOps, ITIL, ITSM, COBIT, PRINCE2, TOGAF, Kanban...

14 лет в эфире. 3 000 записей. 10 000+ постоянных подписчиков.

 

 

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Новые экзамены
по ITSM
Реестр ESM- и ITSM-систем в России 2024

Измеряем Incident management

Продолжаем публикацию находок по измерению процессов управления ИТ, начатую в заметке «Измеряем Problem management». Примеров метрик по процессу управления инцидентами множество. Пожалуй, это самый изученный с точки зрения измерения процесс ITSM. Однако в очередном проекте мы в который раз столкнулись с вопросом: как реализовать метрику, которая бы показывала долю ответственности заданной группы поддержки в нарушении сроков обработки инцидентов. Вопрос давний и непростой. Сложности связаны с тем, что в обработке одного инцидента могут принять участие несколько групп (за счёт функциональной эскалации). Традиционное решение «вешать просрочку» на последнюю группу, обрабатывавшую инцидент, обладает рядом очевидных минусов. В самом деле, эта группа могла получить…

ИТ-метрики: четыре главные ошибки

Боб Льюис (IT Catalysts) написал озаглавленную так статью в блоге на infoworld.com на тему связи целей и метрик. Из своего опыта, Боб выделяет четыре ошибки при выборе процессных метрик, которых следует избегать: Измерять то, что нужно, неточным образом Измерять не то, что нужно Отказываться измерять действительно важные вещи Мотивировать сотрудников на основании процессной метрики Как бы вам не хотелось совершить последнюю ошибку – делать этого не стоит. Сообразительные сотрудники (такие же, как и SMART-цели) почти всегда смогут "обыграть" систему измерения, вне зависимости от того, какие метрики вы им навяжете. Подробности читайте в статье Боба.

О конкурсах

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

Управление ожиданиями

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

Аналитик Forrester хочет отменить CAB

Глен О'Доннел из Forrester Research пишет в своём блоге: Главный виновник негибкости изменений – это Консультативный комитет по изменениям (CAB). CAB – это анахронизм. На пути к гибким облачным решениям CAB играет роль лежачего полицейского. В CAB часто участвуют жадные до власти эгоцентристы, которые просто хотят контролировать процесс, но не поддерживать интересы заказчика. Вне зависимости состава, участники CAB не имеют понятия и реальных условиях. Мир стал слишком сложен для этого комитета, поэтому суждения участников трудно принять на веру. Даже самые подкованные технари не поспевают за усложнением. А в состав CAB редко включаются именно такие люди, что еще больше удаляет CAB…

ISACA выпустила COBIT Assessment Programme

На этой неделе ISACA (Ассоциация по аудиту и контролю информационных систем) объявила о публикации полной версии программы оценки процессов по COBIT 4.1 В программу входит три документа: Уже известная нам Process Assessment Model Инструкция для аудитора COBIT Assessor Guide: Using COBIT 4.1 Инструкция для самооценки COBIT Self-Assessment Guide: Using COBIT 4.1 Интересно, что инструкции для аудита и самооценки поставляются вместе с Tool Kit: набором шаблонов отчётов, электронных таблиц и презентаций Power Point который позволит почти не задумываясь проводить оценку и представлять результаты в универсальной форме. Купить все три составляющие программы можно на сайте ISACA. Набор для самооценки доступен для скачивания…

Три секрета ITIL-проектов от CoreITSM

Новая запись в дневнике Core ITSM (Джеймс Финистер) озаглавлена "Три секрета успеха ITIL". Джеймс видит следующие факторы, необходимые для того, чтобы ITSM-проект удался: Удачный выбор момента Секрет успеха многих инициатив в том, что они были запущены именно в тот момент, когда стали востребованы. Но как выбрать такой момент? На коротком этапе слияния или поглощения компании: существенное изменение, влияющее на всю организацию Во время "переворотов" в сложившейся рутине, например назначение нового генерального директора организации Когда ключевые заинтересованные стороны хотят перемен, прежде всего, заказчики и поставщики Когда у руководителя есть более значительные задачи, в решение которых удачно встраивается ITSM. Персонал и Партнеры…

Используют ли лидеры ITIL?

Журнал РБК в декабрьском номере опубликовал очередное исследование, в этот раз – рейтинг эффективности крупнейших российских продуктовых ритейлеров по итогам первой половины 2011 года. Чем хорош этот список: в нём эффективность оценивается всего по двум понятным и прозрачным критериям: чистая выручка на одного работника чистая выручка на 1 кв.м. торговой площади В первой пятёрке встречаются (что неудивительно) такие компании как "Ашан Россия" и "Метро Кэш энд Керри Россия". Можно предположить, что продуктовый ритейл достаточно зависим от информационных технологий, особенно когда число магазинов измеряется десятками, число сотрудников тысячами, ассортимент – десятками тысяч, а география вообще непонятно как измеряется. В задаче спрашивается…

At Your Service: ноябрь 2011

Опубликован ноябрьский номер официального журнала itSMF "At Your Service". В этом выпуске: Большая статья Карен Феррис про фреймворк от NBS, посвященный устойчивости бизнеса (sustainability) к изменениям и управление портфелем изменений Исследование Дерека Мадей, посвященное ASL (Application Software Library). Дерек описывает ценность для бизнеса от применения этой библиотеки (почитать о ней можно, например, здесь) Большой набор рекомендаций по организации Service Desk "с нуля", на уровне практических действий – от Тодда Бриджмана Опубликованна запись из журнала Пола Вилкинсона про Героев и Нытиков в ИТ (Help Ensure Responsibility & Ownership и Why? Isn’t My Problem!). PDF-версия журнала, как обычно, доступна для скачивания.

Разработка и эксплуатация

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

Пользователь против заказчика

Я часто вижу и удивляюсь, что управление уровнем услуг (Service Level Management) привлекает внимание со стороны сотрудников технической поддержки. Они пытаются найти в этом процессе ответы на свои вопросы. Причина этого внимания, как мне кажется – толкование ИТ-услуги как «обслуживания»: работа с клиентом в процессе потребления (автосервис, ресторан и так далее). А ведь во многих сводах знаний (в том числе и в ITIL) подчёркивается разделение «клиентов» на заказчиков и пользователей. Заказчик платит ИТ за результат, чтобы достичь своей выгоды. Пользователь, извините, использует результаты ИТ, чтобы ему было удобно делать свою работу. Чувствуете, куда веду? Конечно. Акула капитализма и член профсоюза…

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;