Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
Событие не считается инцидентом в ITIL, если оно связано с плановыми работами, такими как техническое обслуживание или обновления, которые были заранее согласованы и объявлены пользователям. Например, если печать документов недоступна из-за запланированных работ с сетевым принтером, это не классифицируется как инцидент. Однако, если пользователь не был уведомлен о таких работах, возникает вопрос о качестве коммуникации, который может потребовать отдельного рассмотрения.
Минимизировать задержки при перенаправлении обращений между регионами можно несколькими способами. Во-первых, создать четкие критерии, когда обращение должно быть перенаправлено, чтобы избежать ненужных передач между регионами. Во-вторых, обеспечить передачу полной информации при перенаправлении, чтобы специалисты следующей группы сразу могли приступить к работе без дополнительных запросов. В-третьих, установить стандартные временные рамки для каждой стадии обработки и мониторить их выполнение. Также можно разработать шаблоны ответов для пользователей, информирующие о перенаправлении обращения и примерных сроках рассмотрения, что снизит уровень недовольства.
Первый шаг Коттера по разрушению текущих комфортных условий перекликается с моделью изменений Курта Левина (этап «Разморозка») и моделью Вильяма Бриджеса (первая фаза «Завершение и потеря»). Все эти подходы подчеркивают необходимость разрыва привычных шаблонов поведения перед тем, как внедрять новые процессы и правила.
Составление подробных нормативов на выполнение работ является сложной задачей, потому что требуется создать и постоянно обновлять свод всех атомарных операций, из которых могут формироваться любые комплексные задачи. Это требует значительных ресурсов и времени, сопоставимых с работой специализированных институтов, как в строительной отрасли. Кроме того, в условиях постоянно меняющихся технологий и процессов поддержание актуальности такого свода нормативов представляет собой непрерывный и трудоемкий процесс.
Приоритет зависит от цели измерения. Для оперативного управления (например, мониторинг инцидентов в реальном времени) важнее скорость получения данных, даже с погрешностью. Для стратегического анализа (например, планирование изменений в процессе) критична точность, и допустимы задержки. Например, грубая автоматизированная метрика доли обращений с переклассификацией полезна для ежедневного контроля, а выборочный ручной аудит — для корректировки стандартов работы.
При организации учёта трудозатрат ключевая проблема с 'квантом времени' заключается в завышенной оценке сотрудниками своих трудозатрат из-за восприятия одновременного выполнения нескольких задач как работы над всеми ними сразу. Например, сотрудник может вести телефонный разговор, консультируя клиента, и одновременно заполнять документацию. В реальности время, затрачиваемое на каждое действие, неделимо и требует чёткой фиксации. Для решения этой проблемы рекомендуется фиксировать начало и конец комплекса действий, затем оценивать долю времени, потраченного на каждую задачу. Стандартный приём — разделение общего времени поровну (50/50) между задачами и дальнейшее уточнение на основе личных наблюдений.
Путешествие заказчика по ITIL включает несколько ключевых этапов: Offer (Предложение), Agree (Согласование), Co-create (Совместное создание), и другие. На этапе Offer происходит сбор требований к услуге, на этапе Agree - согласование и фиксация условий услуги и требований к уровню обслуживания (SLA). Этап Co-create связан с непосредственным предоставлением услуги и взаимодействием пользователя с провайдером в процессе использования услуги. Каждый из этих этапов может запускать определенные потоки создания ценности в зависимости от типа взаимодействия и предъявляемого спроса.
Прямая выдача доступа без согласования невозможна, так как при этом затрагиваются интересы различных сторон, которые необходимо учесть. Разные участники процесса отвечают за разные аспекты: руководитель - за соответствие задачам сотрудника, владелец ресурса - за защиту бизнес-интересов, технические администраторы - за стабильность системы, внутренний контроль - за соблюдение принципа разделения обязанностей, информационная безопасность - за соответствие политикам безопасности. Пропуск любой из этих проверок может привести к нарушению бизнес-процессов, регуляторных требований, создать риски безопасности или технические проблемы в работе информационных систем.
Критерий доступности важен для однозначной трактовки того, что считать периодом недоступности услуги. Это позволяет избежать споров внутри ИТ-организации и с заказчиком относительно того, следует ли учитывать тот или иной сбой как инцидент недоступности. Чёткое определение критерия доступности позволяет корректно формировать отчётность, которая напрямую влияет на восприятие заказчиком качества оказываемых услуг и его удовлетворенность.
Сквозная ответственность предполагает назначение координаторов изменений, которые отвечают за весь жизненный цикл конкретной модели или моделей изменений. Эти люди должны сопровождать изменения от начала до конца, обеспечивая целостность процесса. Определение координаторов может быть простым или сложным в зависимости от принципов выделения услуг и других факторов. Их роль критически важна для успешного управления изменениями.