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

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

25
авторов

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

100%
оригинальный контент
Информация о major-инциденте для первой линии поддержки должна включать: описание происшествия с указанием, что произошло и в какое время, ожидаемое время решения; уникальный идентификатор инцидента (ID) для установки связей с поступающими обращениями пользователей; оценку влияния на ИТ-услуги, опирающуюся на данные CMDB, чтобы понимать, каким пользователям и в какой степени оказывается влияние, а также уровень критичности проблемы. Эти данные позволяют первой линии давать точные ответы на вопросы пользователей и управлять потоком обращений.
Для доноса информации и знаний до коллег используются различные инструменты: обязательная практика информирования о проектах и их результатах, встроенная в проектную практику; рассылка или публикация повестки и решений CAB; поощрение ведения профессиональных блогов и добавления новых записей в корпоративное хранилище знаний; регулярное обучение специалистов новым знаниям и сформировавшимся ноу-хау; обеспечение доступности информации через инвестиции в UX, поисковые технологии и современные интерфейсы, включая голосовые системы.
Успешные ИТ-менеджеры должны уметь оценивать взаимодействие с пользователями, поставщиками, партнерами и заказчиками, чтобы оптимизировать предоставляемые услуги. Ключевыми являются навыки понимания опыта и потребностей заинтересованных сторон, умение проводить анализ и картографирование их взаимодействия с продуктом или услугой.
Согласно ITIL 4, услуга определяется как способ обеспечения совместного создания ценности через содействие заказчикам в получении конечных результатов, которых они хотят достичь, без владения специфическими затратами и рисками. Важно, что услуга представляет собой не просто предоставление услуги, а процесс, в котором поставщик и клиент совместно создают ценность в рамках сервисных отношений.
Стандартное изменение - это изменение услуги или другой конфигурационной единицы, для которого управлением изменениями заранее авторизован подход к его выполнению, и этот подход основан на отлаженной и утверждённой процедуре предоставления конкретного (заранее определённого) результата. Это изменения с низким риском, которые могут внедряться без дополнительной авторизации для каждого отдельного случая, при условии что модель их выполнения уже прошла комплексную оценку рисков и авторизацию. Авторизация требуется на уровне разработки самой модели выполнения стандартного изменения, а не для каждого конкретного экземпляра такого изменения.
Основные причины следующие: 1. Дочерним аутсорсерам не разрешают получать адекватную прибыль или применяется схема cost plus (1-2%), что мотивирует руководство аутсорсера на снижение эффективности для формирования запасов ресурсов. 2. Отсутствие жестких планов коммерческой деятельности на открытом рынке, что лишает аутсорсера стимулов к повышению качества и развития бизнеса, делая его инертным. 3. Вывод в аутсорсинг уникальных услуг, связанных с глубоким пониманием бизнес-процессов материнской компании. Это создает монополию на специализированные и базовые услуги, позволяя манипулировать ценами.
Основные проблемы при переходе к гибкому управлению в ИТ-разработке включают: сопротивление сотрудников изменениям, так как у них уже сложились устойчивые процессы и они чувствуют себя комфортно в текущей системе; отсутствие продуманной стратегии и плана изменений; попытки ограничиться локальной оптимизацией отдельных процессов вместо системного подхода; трудности в определении четких границ ИТ-продуктов из-за сложной структуры бизнеса, когда одна система поддерживает несколько бизнес-направлений или одна бизнес-область обслуживается несколькими системами; сложности масштабирования гибкого управления на крупные коллективы, особенно если ранее существовала жесткая иерархическая культура; отсутствие стандартов работы и показателей эффективности, что приводит к непониманию того, что считается нормальной работой.
Управление доступностью ИТ-услуг (AVA) фокусируется на рисках с высокой вероятностью возникновения, в то время как управление непрерывностью ИТ-услуг (CONT) сосредоточено на рисках, связанных с высоким ущербом, таких как чрезвычайные ситуации и катастрофы. AVA рассматривает незначительные и короткие сбои, не имеющие серьезного влияния на бизнес, включая отказы отдельных компонентов, тогда как CONT учитывает только события, которые потенциально приводят к значительному ущербу независимо от их вероятности. Это включает такие ситуации, как пожары, затопления, длительные отключения электроэнергии или недоступность целых дата-центров.
Пользователь (user) - это тот, кто непосредственно пользуется ИТ-услугами в своей работе. Заказчик (customer) - это тот, кто определяет потребности, формирует задачи и, главное, оплачивает услуги. Заказчик может не использовать услугу напрямую, но влиять на формирование каталога услуг и бюджета. Например, руководитель подразделения может являться заказчиком для ИТ-службы, даже если он лично не использует все предоставляемые услуги.
Основная цель процесса «Управление проблемами» (Problem Management) в рамках ITIL заключается в минимизации негативного влияния на бизнес инцидентов, вызванных ошибками в ИТ-инфраструктуре, и предотвращении повторного возникновения таких инцидентов. Процесс направлен как на реагирование на уже произошедшие инциденты с устранением их корневых причин, так и на проактивное выявление потенциальных проблем, способных вызвать инциденты в будущем, чтобы предотвратить их возникновение.