Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.

6170+
вопросов и ответов

25
авторов

440+
источников

100%
оригинальный контент
Показателями успешности «бумажного» процесса перед автоматизацией являются стабильное соблюдение регламента участниками, минимальное количество ошибок и отклонений, положительная обратная связь от сотрудников, демонстрация эффективного решения поставленных задач и чёткое понимание требуемых доработок системы. Также важно, чтобы процесс показывал измеримые улучшения в ключевых метриках, например, сокращение времени выполнения операций или повышение качества результатов, что подтверждает корректность его логики и готовность к переходу на автоматизированный режим.
В ITIL Service Design примеры SLA и OLA очень похожи потому, что содержательно эти документы практически не отличаются. OLA формально описывает внутренние обязательства, которые поддерживают выполнение SLA, но структура и содержание этих документов таковы, что их можно заменить друг на друга без потери смысла. Это свидетельствует о том, что нет принципиальной разницы между SLA и OLA, а различие заключается лишь в том, с чьей точки зрения рассматривается документ. Отсюда следует, что термин OLA не добавляет существенной ценности и может быть избыточным.
Различные уровни обслуживания по одной услуге в каталоге необходимы преимущественно в сценариях массового обслуживания, где у одной и той же услуги может быть множество заказчиков, каждый из которых имеет различные требования и готов платить за разные уровни сервиса. В таких случаях каталог услуг должен отражать различные пакеты услуг с соответствующими уровнями обслуживания и ценами. Однако во внутренних ИТ-подразделениях, где обычно присутствует один основной заказчик (бизнес), и использование единой инфраструктуры ограничивает технические возможности варьирования уровня услуги, такие различия часто избыточны.
Для оптимизации решения в условиях ограниченного влияния на смежные отделы рекомендуется создавать отдельные связанные проблемы с назначением ответственных координаторов для каждой области. Это позволяет каждому отделу работать над своими задачами параллельно, сохраняя при этом взаимную связь проблем для контроля и координации. Дополнительно можно искать внутриорганизационные пути решения, такие как оптимизация приложений или перераспределение ресурсов.
Помимо USM (Universal Service Management) и eSCM-SP (eSourcing Capability Model for Service Providers), в тексте упоминается подход, аналогичный eTOM (Enhanced Telecom Operations Map), но адаптированный для более широкого спектра услуг. Автор полагает, что существует потребность в промежуточном варианте между USM и eSCM-SP - уровне сложности, близком к eTOM, но с обобщением на различные виды услуг. Такой подход должен сохранять простоту понимания, присущую USM, но иметь большую детализацию, чем это предлагается USM, и в то же время быть менее сложным, чем eSCM-SP.
Автор считает, что должен существовать промежуточный уровень между USM и eSCM-SP, потому что USM слишком простой, а eSCM-SP слишком сложный для практического применения. Автор видит потребность в подходе, который будет близок по сложности к eTOM, но с возможностью обобщения на различные виды услуг, а не только телекоммуникационные. Такой промежуточный уровень должен сохранить простоту понимания USM, иметь достаточную детализацию, чтобы быть практически полезным, и не быть перегруженным сложностью eSCM-SP, что сделало бы его малоприменимым для многих организаций.
Типичный диапазон значения Incident Rate составляет от 0.8 до 1.2 инцидентов в месяц на одного пользователя. Крайние случаи могут достигать 0.4–2.3, но чаще всего величина находится в пределах 0.3–2.0. Для сравнения, совокупное количество всех обращений пользователей (включая сервисные запросы и инциденты) колеблется от 1 до 2 в месяц на одного пользователя.
Существует два основных типа функциональной эскалации: с произвольным маршрутом и с фиксированным маршрутом. При эскалации с произвольным маршрутом специалист, отвечающий за обработку инцидента, самостоятельно выбирает следующий шаг в зависимости от результатов диагностики. При эскалации с фиксированным маршрутом для каждой ИТ-услуги заранее определен состав линий поддержки и ответственность каждой линии. Фиксированный маршрут представляет собой строгую последовательность передачи инцидента между уровнями поддержки (например, L2-L3-L4), где каждый уровень имеет конкретные полномочия и зону ответственности.
Наличие общей цели является ключевым условием для существования именно команды, а не просто рабочей группы. В команде люди ведут себя иначе, чем в индивидуальных коммуникациях – проявляются специфические групповые эффекты, обусловленные человеческой психологией. Общая цель объединяет участников, создает основу для самоорганизации и позволяет эффективно использовать групповые эффекты, такие как синергия идей. Без общей цели участники просто делят между собой задачи, формируя рабочую группу, которая работает иначе и требует иного подхода к управлению. Только наличие общей цели позволяет использовать преимущества командной работы и достигать лучших результатов через взаимодействие и коллективные усилия.
Привязка инцидентов к изменениям затруднена из-за отсутствия четких критериев и процессов для определения причинно-следственной связи. Неясно, как и кто должен принимать решение о том, что инцидент вызван конкретным изменением. Специалисты часто сосредоточены на быстром устранении инцидента и не уделяют достаточно внимания корректной привязке к изменениям, что делает данные неточными. Отсутствует мотивация у сотрудников выполнять эту дополнительную работу, так как это не входит в их основные задачи по решению инцидентов.