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

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

Измерение и оценка ИТ

Всё о метриках, KPI, CSF, а также об измерении услуг, процессов, технологий. И про CleverKPI.

Об измерении вреда

Сегодня мы закончили пилотное чтение нового курса. Новый курс называется “Оценка процессов управления ИТ”, и условно его можно разделить на две части: “Оценка процессов снаружи” и “Оценка процессов внутри”. Первая часть – про оценку дизайна ИТ-процессов, состава реализованных практик и организации управления, контроля и совершенствования: ISO 15504, COBIT PAM, TIPA и наши собственные инструменты для диагностики процессов. А вторая – про метрики и показатели, используемые для управления: показатели результативности, рациональности/эффективности и другие доступные менеджерам различного уровня линейки и градусники. В пилоте участвовали слушатели, искренне интересующиеся темой оценки процессов и отлично подготовленные, поэтому вести курс было непросто, но чрезвычайно интересно. Пользуясь…

Удовлетворённость: измерять или нет?

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

ITIL: восьмой процесс, третья попытка…

В начале июня наш финский друг Aale Roos получил из itSMF довольно традиционный опрос о внедрении процессов ITIL – если судить по таким опросам, основные процессы ITIL должны были быть внедрены у всех, давно и не однажды. Это ироническое по сути замечание навело Аале на мысль провести свой собственный опрос (мы с вами помним, что Аале, в далеком прошлом статистик, любит и умеет проводить опросы) среди финских компаний об их опыте построения процессов ITIL. Подробные результаты можно найти на сайте компании Аале, а я приведу здесь два любопытных результата: Во-первых, большинство респондентов вспомнили более одного ITIL-проекта, в среднем – три…

ITMF2014: оцениваем процессы и размышляем над уроками

5 июня на XI форуме по управлению ИТ (ITMF2014) среди прочих интересных выступлений был проведен кейс-тренинг по оценке процессов. Участникам была предложена такая ситуация:  В связи со сменой владельцев в торговой компании проводится комплексная оценка действующих практик управления. В частности, новые руководители компании хотят получить оценку процессов управления ИТ. Вообще-то, руководство интересуют:  соответствие практик управления ИТ целям и приоритетам бизнеса; уровень ИТ-рисков; эффективность (рациональность) деятельности по управлению ИТ; соответствие практик управления ИТ рекомендациям и требованиям отраслевых сводов знаний и стандартов. Но с учётом ограничений по времени и стоимости оценки, а также ввиду отсутствия формализованных целей и приоритетов бизнеса, да и…

“Ненастольные” игры

Празднуя пятилетие компании, мы, помимо других развлечений, дружно играли в настольные игры. Некоторые из них имеют довольно сложные правила, в том числе схемы подсчета очков, определяющие, кто в итоге был молодцом и всех победил. Интересно, что подсчет очков реализован так, чтобы мотивировать игроков совершать определенные действия (покупать, строить, мудрить и так далее, в зависимости от игры). Путём такой мотивации достигается основная цель – игра становится интересной/динамичной/веселой и т.д. без подсчета очков и определения победителей игра обычно получается вялой, скучной или механической.   На свежем воздухе подумалось, что можно провести параллели с процессами, которые тоже живут по своим правилам: есть метрики,…

Два верных способа обеспечить контроль выполнения задач

Любой руководитель знает, что для того, чтобы задача была выполнена, совершенно недостаточно просто о ней сообщить сотруднику. Необходимо задачу как можно более чётко сформулировать, описать требуемый результат, желательно упомянуть зачем, кому и почему всё это надо, определить сроки и, самое главное – обеспечить контроль. Раньше я думал, что контроль важен только для тех сотрудников, которых можно условно отнести к исполнителям. То есть тех, у кого нет своих подчинённых, и чей круг задач ограничен известным словосочетанием “manage self“. Например, когда я руководил технической поддержкой, то вопрос необходимости контроля даже не поднимался – необходимость была очевидна. Не менее очевидны были применяемые инструменты, как…

Метрики управления проблемами от ИТ-скептика

ИТ-скептик (в миру Роб Ингланд), споря со статьей Симона Хиггинсона на портале The ITSM Review, предлагает несколько собственных KPI для управления проблемами. Есть несколько замечаний: У проблемы обычно несколько причин. Объявлять единственную причину «корневой» – значит быть субъективным. Например, если время диагностики ограничено: «ой, наше время вышло, волевым решением объявляем обнаруженную причину корневой». Продолжительность диагностики и продолжительность исправления нужно измерять, чтобы выявлять тенденции. Но можно ли использовать их в качестве целевых показателей? «Доктор, вам нужно продиагностировать всех пациентов за два часа». Или: «Пожарный, вы должны устранять маленькие пожары за три дня, средние за восемь часов, а огромные пожары за два часа». Надо помнить,…

За и против COBIT 5 PAM

Я после публикации своей статьи часто вступаю в дискуссии по поводу применимости модели оценки процессов COBIT 5 PAM. Хочу тут свести воедино критические аргументы (не против статьи, а против модели) и то, как на них можно отвечать: Эта модель оценки процессов только для «крупных» компаний сработает. В моей маленькой ИТ-команде этого ничего не надо. Конечно же, только для крупных. Настолько крупных, что «по памяти» работать уже не получается: слишком большой становится вариативность. Для снижения вариативности деятельность загоняется в рамки-заборы напоминаний, распределения обязанностей, автоматизации, измерения, совершенствования, вы поняли. А если уж вы поставили забор вокруг газона, то придётся вам его регулярно проверять,…

Что писать в SLA?

Вот замечательнейший же шаблон SLA дан в ITIL. Все по пунктам, с объяснениями, без лишней воды. Бери и знакомься с идеей соглашения об уровне услуги: Описание услуги. Автоматизируемая деятельность предприятия. Охват. Территория, организационные подразделения, типы автоматизируемых операций. Охват содержит разграничение ответственности предприятия и поставщика услуги. «Стрижку сделает парикмахерская, укладку каждый день – клиент». Режим предоставления услуги. Функциональность, включая допустимое количество ошибок. Используется для определения доступности. Доступность. Надежность. Мощность (время отклика, толщина канала связи, квота данных, скорость вычислений, количество пользователей и т.д. и т.п., насколько хватает фантазии и способов измерения). Непрерывность. Здесь ссылка на планы поведения в чрезвычайных ситуациях. Безопасность. Ссылка на…

Измерение процессов. Incident Management. Часть 3

Как известно, назначение процесса управления инцидентами – минимизировать негативное влияние на бизнес посредством скорейшего устранения инцидентов. Измерение результативности процесса управления инцидентами чаще всего выполняется двумя метриками: доля своевременно решенных инцидентов и среднее время устранения инцидентов (в разбивке по уровню влияния или приоритету – в зависимости от того, как определяется срок устранения инцидента). Но, строго говоря, ни одна из этих метрик не отвечает на вопрос, насколько удается устранять инциденты скорейшим образом (то есть не просто быстро, а максимально быстро). Можно ли каким-то образом ближе подобраться к ответу на этот вопрос? Попробуем. ITIL описывает очень полезный и хорошо применимый на практике аналитический инструмент…

Процессная математика. Опросы пользователей

Постановка задачи Допустим, мы решили провести опрос пользователей. Известно, что всего их – 1 000 человек. Для простоты предположим, что мы задаём 1 вопрос (например, об удовлетворенности качеством поддержки) с ответом по пятибалльной шкале (1-5). Интересующий нас результат опроса выражается средним из полученных ответов. Вопрос: сколько ответов пользователей необходимо получить, чтобы результаты опроса были достаточно точными (достаточно – для принятия на основании результатов опроса управленческих решений)? Ответ первый: на основании здравого смысла (то есть предрассудков) Я опросил несколько знакомых, как они думают, сколько голосов пользователей необходимо получить. Ответы ранжировались в диапазоне 10-50% голосов от общего количества участников опроса, наиболее часто –…

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM