Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
SIP становится эффективным инструментом управления благодаря тому, что представляет собой набор конкретных заданий в системе автоматизации процессов ITSM, а не формальный документ. Такой подход позволяет фиксировать не только намерения по улучшению услуг, но и фактические результаты работы над ними. SIP становится измеримым, так как позволяет сопоставлять активности в рамках программы с реальной динамикой удовлетворенности клиентов, обеспечивая обратную связь для корректировки приоритетов и методов работы над улучшением качества услуг.
Для внедрения SMART-подхода в управление ITSM-процессами необходимо для каждого процесса сформулировать цели, соответствующие критериям Specific (конкретность), Measurable (измеримость), Achievable (достижимость), Relevant (релевантность), Time-bound (ограниченность сроками). Например, цель для процесса управления инцидентами: 'Сократить среднее время устранения инцидентов с критическим приоритетом до 2 часов к концу квартала'. Эти цели должны быть привязаны к назначению процесса и измеряться через влияние на качество ИТ-услуг.
Книга дает практичные рекомендации по началу внедрения ITSM, обосновывая их через призму общей концепции управления, где каталог ИТ-услуг выступает ключевым звеном. Авторы предлагают начать с определения, какие услуги ИТ предоставляет бизнесу, как они связаны с бизнес-процессами и каковы ожидания бизнеса от этих услуг. Это позволяет создать основу для последующего внедрения других процессов ITSM, таких как управление инцидентами, проблемами, изменениями и релизами. Подчеркивается важность формирования четкого понятийного аппарата и бизнес-ориентированного подхода с самого начала проекта.
Определение значения N для расчёта метрик FLR и FCR является сложной задачей, потому что далеко не все обращения возможно разрешить на первой линии. Часть заявок физически невозможно решить удалённо, часть нельзя обрабатывать из-за ограничений регламентов или политик, а часть требует уровня доступа, которым не обладают сотрудники первой линии. Если учитывать все обращения в расчёте, это приведёт к искажению результатов, так как первая линия не может влиять на те обращения, которые технически не могут быть разрешены на её уровне. Это делает показатель плохо применимым для объективной оценки эффективности работы первой линии.
При определении приоритетов изменений необходимо учитывать потенциальные выгоды от внедрения, связанные с ожиданиями инициатора относительно срочности, а также распределять задачи между исполнителями. Важно отметить, что часто возникают конфликты интересов, когда в общую совокупность задач попадают изменения, запрошенные разными заказчиками. Для разрешения таких конфликтов необходимо устанавливать приоритеты не только внутри задач, но и «между заказчиками», что усложняет процесс и требует уточнения коммуникации и прозрачности процесса расстановки приоритетов.
Почему важно оценивать критичность каждой обязанности владельца процесса для конкретной организации?
Оценка критичности каждой обязанности владельца процесса необходима для того, чтобы понять, какие из этих обязанностей действительно жизненно важны для конкретной организации и конкретного процесса. Это помогает определить реальные требования к роли владельца, вместо формального назначения, когда человек не обладает достаточными полномочиями для выполнения всех пунктов. Например, в организации, только внедряющей процессный подход, может быть критически важным, чтобы владелец процесса имел полномочия, охватывающие все подразделения, участвующие в процессе, чтобы преодолевать сопротивление изменениям. В то время как в более зрелой процессно-ориентированной организации достаточно назначить владельца с ограниченными полномочиями, так как существующие механизмы будут компенсировать этот недостаток. Такой подход позволяет избежать ситуаций, когда владелец процесса формально назначен, но не может реально управлять процессом из-за недостатка полномочий.
Ресурсный характер ИТ-услуг значительно усложняет обоснование нересурсных ИТ-проектов, так как бизнес склонен оценивать ценность только по видимым результатам и прямой полезности. Когда основная ценность для заказчика заключается в конечных ресурсах (приложениях, устройствах), объяснить необходимость инвестиций в процессы, стандарты, инструменты управления становится крайне сложной задачей. Бизнес-спонсорам трудно понять, как работы по улучшению управления изменениями, инцидентами или конфигурациями непосредственно повлияют на их бизнес-результаты. Поэтому ИТ-менеджерам приходится транслировать ценность процессных улучшений в терминах бизнес-полезности, что часто требует значительных усилий по преобразованию скрытых гарантий в явные бизнес-преимущества.
Организационная структура, способная обеспечить кратное ускорение, характеризуется следующими особенностями: минимизированной иерархией в пользу самоорганизованных команд, которые обладают достаточной автономией для принятия решений по своим задачам; чёткими границами ответственности, позволяющими командам работать параллельно без постоянных конфликтов; фокусом на конечных результатах и бизнес-ценности, а не на процессных показателях; системой приоритизации, которая учитывает не только срочность, но и ценность задач для бизнеса; и наличием обратной связи о влиянии работы команды на бизнес-результаты. Такие структуры создают условия для оперативного реагирования на изменения и быстрой доставки ценности конечным пользователям.
V-модель эффективна для объяснения взаимосвязи между процессами ИТ-управления,因为她 визуализирует, как различные процессы (тестирование, управление изменениями, управление релизами, управление конфигурациями) связаны между собой через общий жизненный цикл проекта. Она показывает, как решения, принятые на этапе проектирования, влияют на последующее тестирование, как управление конфигурациями обеспечивает основу для управления изменениями, и как все это вместе гарантирует, что конечный продукт соответствует изначальным требованиям. Модель создает целостное представление, где каждый процесс виден не изолированно, а как часть единой системы, что помогает лучше понимать их взаимодействие и взаимозависимость
Термин 'владелец услуги' (service owner) в практике управления ИТ-услугами означает лицо, которое несет ответственность за сквозное управление конкретной ИТ-услугой. Владелец услуги отвечает за полный жизненный цикл услуги и за обеспечение ее соответствия потребностям бизнеса. Это ключевая роль в управлении услугами, определяемая как 'отвечающий за end-to-end управление конкретной ИТ-услугой'. Эта роль отличается от менеджера уровня услуг тем, что фокусируется на самой услуге в целом, а не на конкретных соглашениях об уровне услуги.