Для сбора статистики по трудозатратам на сопровождение CMDB можно применить несколько подходов. Оптимальный подход - ведение полного или выборочного учета трудозатрат, который предполагает 'списание часов' на задачи, выполненные в течение дня. Это позволяет получить точную статистику, на основании которой легко планировать необходимые ресурсы. Если такой учет не поставлен, можно воспользоваться консолидированной статистикой с портала REALITSM.RU, где участники могут делиться своей статистикой и наработками по оценке трудозатрат на сопровождение CMDB. Также можно произвести оценку трудозатрат на основе нормирования отдельных задач сопровождения CMDB в разбивке по группам конфигурационных единиц и ролям специалистов, учитывая требования к компетенциям исполнителя и различную стоимость рабочего времени для разных категорий специалистов.

Необходимость новой метрики определяется через ответы на три вопроса: 1) Решает ли она конкретную управленческую задачу? 2) Можно ли изменить действия команды на основе ее значений? 3) Соизмеримы ли затраты на сбор данных с ожидаемым эффектом? Например, метрика «доля обращений с некорректной классификацией» оправдана, если данные искажения приводят к ошибкам в отчетности или ухудшению качества сервиса. Если улучшение метрики не влияет на другие показатели, от нее стоит отказаться.

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

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

Если не использовать понятие 'переоткрытый инцидент', существуют альтернативные методы отслеживания повторных обращений. Один из таких подходов заключается в установлении связей между инцидентами в системе автоматизации. Это позволяет анализировать, сколько инцидентов связаны с более ранними инцидентами, и на основе этого определять показатели качества обслуживания, такие как FTR. Такой подход может быть более сложным в реализации, если связи между инцидентами используются также для других целей.

Автор сомневается в ценности аналитики Гартнера при выборе ITSM-решений из-за быстрого и непредсказуемого изменения позиций вендоров в магическом квадрате, не подкрепленного существенными изменениями в продуктах. Это вызывает вопросы о том, как компании могут опираться на такую аналитику для принятия решений о стратегических партнерах на годы вперед. Кроме того, критикуется концентрация на оценке поставщиков вместо технических характеристик продуктов, что приводит к усреднению и отставанию от реального состояния ITSM-рынка.

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

В разделе «о чем просим / что требуем» должно быть четко и конкретно указано действие, которое требуется от получателя. Примеры формулировок: «Прошу Вас содействовать / довести до сведения персонала / назначить ответственных / согласовать расходы на…», «Инициировать проект не позднее …», «Начать работы с …». Если вы что-то требуете, важно ссылаться на соответствующее основание из предыдущего раздела (например, приказ или решения встречи), которое подтверждает ваши полномочия в постановке таких требований. Также желательно указать конкретные сроки выполнения задачи. Четкое формулирование запроса и наличие ссылок на нормативные документы или решения значительно увеличивают вероятность получения нужного ответа в требуемые сроки.

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

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