Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
По мере того как программирование становится более верхнеуровневым (то есть отдаляется от управления физическими процессами в «железках» и приближается к человекопонятному языку), коммуникация между разработчиками и бизнесом становится проще. В тексте указано, что это должно сделать легче объяснение сложных технических аспектов бизнесу простым языком. Однако несмотря на это, все еще остается проблема, что многие разработчики не могут эффективно донести суть своей работы до нетехнических специалистов. Тем не менее, сама эволюция программирования в сторону абстракции и верхнеуровневых конструкций создает предпосылки для улучшения взаимопонимания, если разработчики будут учиться адаптировать свое общение к аудитории бизнеса.
ITIL предоставляет рекомендации по запросам на обслуживание, которые идентичны рекомендациям по управлению инцидентами. То есть организации должны предопределить правила относительно возможности повторного открытия запросов на обслуживание и условий, при которых это допустимо. Временные рамки и конкретные условия могут различаться в зависимости от особенностей организации и её требований к обслуживанию.
При отсутствии ранее существовавшей документации по управлению активами и конфигурациями рекомендуется использовать название "План управления сервисными активами и конфигурациями" (SACM plan). Это соответствует рекомендациям ITIL v3 2011 (раздел Service Transition, 4.3.5.2). При необходимости, учитывая специфику организации, название может быть адаптировано к таким вариантам как "Положение" или "Регламент". Ключевой момент - документ должен описывать целевой уровень управления сервисными активами и конфигурациями, который организация определяет самостоятельно. Структура документа должна включать разделы по охвату, требованиям, политикам и стандартам, организационной структуре, описанию процедур и связям с другими процессами.
Процесс учета рабочего времени занимает значительно меньше, чем многие предполагают. За весь 2014 год на эту задачу потребовалось всего 6 часов 4 минуты, что составляет 0,32% всего рабочего времени за год. Это опровергает распространенное мнение о том, что учет времени может занимать от 5% до 10% рабочего времени.
Получение электронного письма от первого лица компании с единственным символом вопроса означает присвоение проблемы кода Sev-B. Получатель должен немедленно прекратить все текущие задачи и в течение нескольких часов разобраться в вопросе, устранить проблему, определить её причины, составить подробный отчет о произошедшем и предложить конкретные меры по предотвращению повторения ситуации. Ответственный сотрудник затем предоставляет результаты проверки своему руководителю, после чего информация передается по иерархической цепочке до самого первого лица, которое лично участвует в обсуждении и принимает окончательное решение.
Контроль необходим всем сотрудникам, вне зависимости от их уровня и должности. Даже опытные менеджеры могут не выполнить задачу в срок или с требуемым результатом по разным причинам: забыть о ней, неверно оценить приоритет, не передать подчиненным или иным образом неправильно понять задачу. Как показывают примеры из практики руководителей крупных компаний, эффективный контроль позволяет своевременно выявлять проблемы и предотвращать отставание от графиков. Даже топ-менеджеры, управляющие другими руководителями, нуждаются в системном контроле выполнения задач.
Для не-ИТ организаций подходят следующие элементы ITIL: управление стратегией (поможет в формировании стратегии и организации системы учета затрат); процесс постоянного совершенствования (CSI); управление службой поддержки и инцидентами; управление конфигурациями (для распределенных сложных инфраструктур); управление изменениями (когда услуги и технологии постоянно развиваются); управление уровнями услуг; управление знаниями. В зависимости от сложности и структуры предоставляемых услуг выбирается та или иная часть рекомендаций ITIL.
Традиционную схему оценки влияния инцидентов можно улучшить следующими способами: 1) Ввести специальные правила для критичных периодов, например, повышать уровень влияния для отчетности в конце месяца. 2) Определить функциональных VIP-пользователей, чьи обращения всегда имеют повышенный приоритет. 3) Установить особые правила оценки влияния для отдельных ИТ-услуг, которые имеют стратегическое значение для бизнеса. 4) Сформулировать более четкие критерии различия между 'частичным' и 'полным' отсутствием функционала. При этом важно сохранять баланс между детализацией правил и их практической применимостью для сотрудников первой линии поддержки.
Преимущество подхода MVP заключается в том, что он позволяет избежать избыточных трат ресурсов на элементы практик, которые не добавляют ценности в текущих потоках создания ценности. Этот подход помогает сосредоточиться именно на том, что необходимо для достижения бизнес-целей, не вовлекаясь в детализацию процессов, которые не являются критически важными. Это особенно полезно для новых организаций, которые только наращивают деятельность, и для существующих организаций, стремящихся оптимизировать свои практики, не тратя ресурсы впустую на излишние компоненты.
Принцип 'Отталкиваться от текущей ситуации' важен потому, что начинать с чистого листа часто приводит к неоправданным затратам ресурсов, времени и энергии, а также к большему сопротивлению со стороны участников изменений. Оценка существующей ситуации и последовательное преобразование деятельности позволяют сэкономить ресурсы и найти меньше сопротивления, так как учитываются текущие инструменты, данные и практики.