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

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

25
авторов

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

100%
оригинальный контент
ITIL V3 относится к необходимости выделения отдельных ролей для координации процессов управления службами достаточно гибко, предоставляя организации возможность самостоятельно определить структуру и ответственность. В стандарте описаны основные процессы и общие рекомендации по управлению, но детальное распределение обязанностей и выделение специфических ролей, таких как "Координатор релизов" или "Координатор изменений", остаётся на усмотрение организации. ITIL фокусируется на результатах процессов, а не на том, какие именно роли их выполняют, что позволяет компаниям адаптировать стандарт под свои нужды, в том числе вводить дополнительные роли тогда, когда это необходимо для эффективности процессов.
В контексте KPI для руководителей поддержки термин "tension-партнер" относится к дополнительной метрике, которая балансирует основную метрику и предотвращает фокус на одном аспекте работы в ущерб другим. Например, если основной KPI - своевременность решения инцидентов, то tension-партнером может быть своевременность выполнения плановых работ, которая не позволяет руководителю полностью сосредоточиться только на экстренных задачах. Это создает "напряжение" между разными аспектами работы и стимулирует руководителя поддерживать баланс между оперативным реагированием и стратегическим развитием системы, предотвращая выгорание команды и накопление технического долга.
Бизнес смотрит на преодоление текущих ограничений ИТ-подразделения как на процесс, который требует времени и планирования. Представители бизнеса заинтересованы в том, чтобы сегодняшние договоренности в SLA содержали элементы будущих улучшений, понимают необходимость развития и готовы к постепенному устранению ограничений через определенные этапы, а не мгновенно.
Информацию от коллег, получаемую на курсах, можно использовать для улучшения собственных знаний и процессов. Например, наблюдая за подачей материала тренерами, можно перенять эффективные методы обучения, а слушая вопросы участников, понять, какие темы сложны для понимания и требуют дополнительного внимания. Также полезно обсуждать сложные случаи и примеры из реальной практики для повышения качества предоставляемых услуг.
Схемы согласований – это регламентированные последовательности этапов и участников, через которые должны проходить заявки или запросы для их окончательного утверждения. Их согласование необходимо, потому что схемы сами по себе могут быть сложными и требовать проверки на соответствие регламентам организации, юридическим нормам и техническим возможностям. Согласование схем предотвращает создание слишком длинных или запутанных цепочек утверждения, определяет четкую ответственность на каждом этапе и учитывает возможные изменения в структуре организации. Это помогает избежать ситуации, когда схема согласования становится устаревшей или неэффективной, что в свою очередь может тормозить все связанные с ней бизнес-процессы.
Выбор между ручным и автоматическим закрытием инцидентов определяется сложностью инцидента, необходимостью подтверждения от пользователя, критичностью проблемы, стандартами процесса и уровнем доверия к автоматизированным системам. Простые и стандартные инциденты часто закрываются автоматически после решения и определенного периода бездействия, в то время как сложные случаи, требующие экспертной оценки или согласования с пользователем, обычно требуют ручного закрытия ответственным специалистом.
Удаление неактуальной информации из CMDB важно для оптимизации процесса управления конфигурациями и сокращения избыточной нагрузки на систему. Сбор и обслуживание ненужных данных занимают ресурсы, которые можно использовать более рационально. Кроме того, наличие в базе данных устаревшей информации может запутать пользователей и привести к ошибочным выводам при анализе состояния конфигурации. Регулярная чистка данных обеспечивает релевантность и полезность CMDB.
Для внутреннего ИТ-провайдера ответы на вопросы портфеля услуг выглядят иначе, чем для внешнего. Клиенты должны покупать услуги, потому что без них бизнес-процессы работать не смогут. Выбора у клиента нет, так как ИТ-отдел - единственный поставщик. Цену услуг не придумывают, а только рассчитывают себестоимость по согласованной методике, монетизация происходит через утверждение бюджета. Сильная сторона - безальтернативность, слабая - восприятие как центра затрат, приоритет - усиление безальтернативности, риск - возможная замена на внешнего провайдера для части услуг. Распоряжение ресурсами происходит по традиционной схеме: получение задачи, ТЗ, проект, закупка ресурсов, эксплуатация.
Внутренние проекты могут полностью остановиться из-за отсутствия ключевых сотрудников, так как заинтересованные стороны имеют меньше стимулов к продолжению работ в их отсутствие. Консультанты же вынуждены поддерживать процесс реализации проекта, соблюдая сроки и стандарты качества, поскольку их работа напрямую связана с договорными обязательствами. Это вынуждает консультантов искать альтернативные решения и перераспределять задачи, несмотря на сложности.
Геометрическая интерпретация удовлетворенности заказчика связана с косинусом угла следующим образом: ответ на вопрос Xi (от 0 до 1) представляется как cos(Фi), где Фi – угол от 0 до П/2. При полном соответствии (Xi=1) угол Фi равен 0, что означает совпадение восприятия поставщика и заказчика. При полном несоответствии (Xi=0) угол Фi равен П/2, что соответствует перпендикулярности их точек зрения. Промежуточные значения Xi соответствуют пропорциональному изменению угла, отражающему степень расхождения во взглядах на качество услуги.