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

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

25
авторов

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

100%
оригинальный контент
Чтобы определить, какой инфраструктурный ресурс затрагивается новыми требованиями к ИТ-услуге (например, изменение графика предоставления или сокращение окон обслуживания), в спецификацию каждой ИТ-услуги необходимо включить перечень ресурсов и инфраструктурных элементов, которые влияют на ее функционирование. Это позволяет быстро определить, какие части инфраструктуры требуют корректировки при изменении условий предоставления услуги.
Перед началом проверки ИТ-процессов на «правильность» необходимо определить задачи, которые должны решаться ИТ-процессами, оценить текущие возможности компании и её ограничения. Также важно провести проверку не только того, что задачи решаются, но и того, что они решаются рационально.
В реальной практике существуют несколько организационных моделей BRM. Первая модель – это выделенная функция в внешних сервис-провайдерах (сервис-провайдеры третьего типа), где сотрудники часто называются account-менеджерами. Их основная задача – проработка возможностей взаимовыгодного сотрудничества сервис-провайдера и заказчика. Такие account-менеджеры остаются точкой контакта для ключевых представителей заказчика и выступают его голосом в сервис-провайдере на всем протяжении предоставления услуги. Вторая модель – внутренние ИТ-подразделения очень крупных компаний, где BRM работают на границе ИТ и бизнеса. Они могут занимать позиции руководителей групп бизнес-аналитиков или быть выделены в отдельную функцию. Их ответственность включает совместное планирование развития услуг с ключевыми заказчиками, оптимизацию портфеля услуг и кураторство комплексных проектов. Ответственность может быть разделена по услугам или по предметным областям заказчика.
При управлении запросами на обслуживание категоризация решает несколько важных задач. Она помогает определить типы и частоту запросов, выявить тенденции в обращениях по различным услугам, а также определить, какие запросы подаются чаще всего. Категоризация запросов может производиться по нескольким критериям: по услуге (классификация запроса как части определенной услуги), по видам деятельности (например, сброс пароля, установка ПО), по типу запроса (информационный запрос или стандартное изменение), по группе поддержки (для определения ответственной команды) и по типу конфигурационной единицы (влияние на определенные компоненты инфраструктуры). Эти классификации позволяют повысить операционную эффективность, улучшить распределение ресурсов и повысить удовлетворенность клиентов благодаря более точному и быстрому выполнению запросов.
Модели стандартных изменений формируются в рамках практики управления изменениями через выявление повторяющихся задач с низким уровнем риска. Процесс включает анализ исторических данных, определение критериев безопасности и эффективности, документирование процедур и предварительную авторизацию. Модель может содержать пошаговые инструкции, определенные маршруты согласования или даже автоматизированные процессы через конвейеры CI/CD. Эти модели должны регулярно обновляться и утверждаться ответственными за управление изменениями структурами организации. Затем модели внедряются в другие практики, такие как управление запросами на обслуживание, для стандартизации выполнения типовых задач.
Интегральный коэффициент доступности отражает суммарную работоспособность всей сети, учитывая отказы отдельных компонентов и их взаимодействие. Высокий коэффициент означает минимальные простои для конечного пользователя, что напрямую повышает качество восприятия услуги. Низкий коэффициент указывает на узкие места в инфраструктуре, требующие модернизации или оптимизации процессов управления. Для бизнеса это критично, так как качество ИТ-услуг напрямую влияет на удовлетворенность клиентов и выполнение условий контрактов.
ISO 31010 представляет собой полное собрание методов идентификации, анализа и оценки рисков. Стандарт охватывает широкий спектр подходов – от организации работы экспертных групп до количественной оценки вероятности негативных событий. Среди описанных методов присутствуют FTA (анализ дерева отказов), ETA (анализ дерева событий), BIA (анализ бизнес-воздействия), метод Дельфи, SWIFT (Структурированный Что-Если Анализ Технологии) и диаграмма Ишикавы. Все эти методы собраны в едином документе, что делает стандарт ценным практическим руководством.
В идеальной производственной системе, построенной по принципу вытягивания, задачи должны двигаться по потоку создания ценности исключительно слева направо, потому что каждая задача последовательно проходит стадии обработки, добавляя ценность на каждом этапе. В то же время информация о состоянии задачи и обратная связь по ней движется справа налево, обеспечивая обратную связь в систему. Такой однонаправленный поток минимизирует издержки, ускоряет время выполнения задач и позволяет лучше контролировать процесс без необходимости возвратов и переделок.
Сервисный подход к управлению ИТ позволяет достичь наиболее тесной интеграции между ИТ и бизнесом, основываясь на принципах предоставления ценности заказчику. Он обеспечивает сквозную ответственность за ИТ-услуги, охватывающую как разработку, так и эксплуатацию, что особенно важно для отраслей с высокой зависимостью от ИТ. Этот подход способствует формированию четкого каталога услуг, улучшению коммуникации между ИТ и бизнесом, а также позволяет более точно оценивать влияние ИТ-процессов на бизнес-результаты. В долгосрочной перспективе он повышает эффективность использования ресурсов и удовлетворенность потребителей ИТ-услуг.
FTR (First Time Resolution) — это показатель, представляющий долю инцидентов, решенных с первого раза без необходимости переделок или доработок. Снижение FTR негативно влияет на процесс управления инцидентами,因为它 указывает на то, что решения не проходят достаточной проверки или не полностью устраняют проблему, что приводит к необходимости повторного рассмотрения инцидентов. Это увеличивает нагрузку на службу поддержки, снижает рациональность процесса, ухудшает показатели эффективности и может негативно сказываться на удовлетворенности клиентов.