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

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

25
авторов

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

100%
оригинальный контент
Современные компании формулируют свою ориентацию на клиента более профессиональным и структурированным языком. Например, одна компания указывает в своём описании: «Основное направление деятельности компании Х – наиболее качественное удовлетворение покупательского спроса». Это подчеркивает стремление к высокому качеству обслуживания, сохраняя суть клиентоориентированности, которая существовала и в девяностые, но в новой форме.
При планировании ресурсов на сопровождение CMDB необходимо учитывать несколько ключевых факторов. Прежде всего, нужно разделить конфигурационные единицы на четыре основные группы: ИТ-системы, бизнес-приложения, технологические элементы бизнес-приложений и инфраструктура, так как разные группы требуют различного подхода к сопровождению. Также необходимо учитывать перечень задач сопровождения: первичная регистрация, обновление статусов, обновление при изменениях, операционный и периодический аудит, инвентаризация и отчетность. Важно учитывать стоимость рабочего времени для разных категорий специалистов и требования к их компетенциям, так как разные задачи обычно выполняются разными специалистами. Необходимо учитывать ширину охвата учета в CMDB, так как чем она больше, тем сложнее оценка трудозатрат. Идеально вести учет фактических трудозатрат («списание часов»), чтобы на основе этой статистики планировать ресурсы. Если такой учет не ведется, можно использовать консолидированную статистику с портала REALITSM.RU.
Процесс «Управление проблемами» участвует в улучшении качества ИТ-услуг через постоянное выявление и устранение корневых причин инцидентов, что ведет к снижению их количества и повторяемости. Системный подход к устранению причин проблем вместо реагирования на их симптомы способствует повышению общей стабильности и надежности ИТ-инфраструктуры. Проактивный анализ позволяет выявлять и устранять потенциальные проблемы до их проявления в виде инцидентов. Кроме того, накопленные данные об известных ошибках и решениях используются для улучшения процессов проектирования и внедрения новых услуг, что в свою очередь повышает качество ИТ-услуг в долгосрочной перспективе.
ITSM-инициативы требуют лидеров, которые способны обеспечивать стабильное развитие и постепенное улучшение сервисов. Такие лидеры должны получать удовольствие от решения текущих проблем, оптимизации процессов и создания комфортных условий для пользователей. Однако в ИТ-среде в основном развивают и ценят навыки, необходимые для разового выполнения проектов, а не для постоянного обслуживания и улучшения сервисов. Это приводит к дефициту специалистов, готовых заниматься долгосрочной работой, что негативно сказывается на реализации и поддержке ITSM-инициатив.
Для определения необходимого объёма данных в системе управления конфигурациями следует сначала проанализировать потребности бизнес-процессов и ИТ-услуг. Нужно выявить, какие процессы и роли будут использовать информацию из CMS, какие конкретные данные им необходимы и как они будут применяться для решения задач. Следует сосредоточиться на сборе именно тех данных, которые имеют прямую ценность для поддержки операционной деятельности и принятия решений. Внедрение должно начинаться с минимального жизнеспособного набора информации и постепенно расширяться по мере выявления реальных потребностей, избегая сбора избыточных данных, которые не используются ни одним из процессов.
Кратного ускорения поставки задач можно достичь за счет нескольких мер: сокращение количества задач в системе (уменьшение работы в прогрессе), фокусировка на завершении текущих задач вместо начала новых, автоматизация этапов, не добавляющих ценность (например, тестирование), минимизация лишней работы. Эти изменения позволяют снизить время ожидания для задач с 95% до 70% и повысить эффективность потока с 3-10% до 30%, что приводит к трехкратному (и более) увеличению скорости поставки без увеличения числа разработчиков или рабочего времени.
Если продуктовая команда не может продемонстрировать свою эффективность и вклад в достижение бизнес-целей, она рискует быть расформированной после второго цикла отчетности. В условиях коммерческой деятельности руководство бизнеса не терпит менеджмент, который не достигает плановых показателей по прибыли, выручке, росту клиентской базы или другим ключевым метрикам. Участники такой команды могут получить негативные оценки профессиональной деятельности, что повлияет на их карьерные перспективы. Это создает необходимую мотивацию для постоянного подтверждения своей ценности через конкретные достижения и результаты.
Роль владельца услуги в ITIL аналогична роли владельца процесса: он занимается целеполаганием и определяет, что нужно достичь через предоставление услуги. Владелец заинтересован в результатах услуги, отвечает за стратегические аспекты и инвестиции, задает цели и ожидания от услуги для бизнеса.
В гибкой среде лучше делегировать команде задачи, которые способствуют развитию самоорганизации и распределения ответственности. Это включает проектирование архитектурных решений (с возможной консультативной ролью тимлида), установление стандартов кода через коллективное обсуждение, распределение задач между членами команды, проведение регулярных встреч планирования и ретроспектив, контроль соблюдения процессов. Эти действия помогают развивать команду как единую систему, где каждый член чувствует ответственность за общий результат, а не перекладывает ее на одного человека.
В неоптимально организованных ИТ-структурах вторая линия поддержки часто сталкивается с такими проблемами: разобщенность специалистов по направлениям, что приводит к нежеланию брать на себя ответственность за задачи вне своей зоны компетенции; формальный подход к обработке задач без учета их срочности и критичности; непрозрачность процессов, делающая невозможным отслеживание реального статуса инцидентов; перекладывание ответственности с одного специалиста на другого без фактического решения проблемы. Третья линия чаще всего страдает от недостаточной коммуникации со сторонними поставщиками и вендорами, задержек в решении вопросов из-за длительных процедур согласования и недостатка технической экспертизы для быстрого анализа и решения сложных проблем.