Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
Для создания единой системы мониторинга распределенных команд поддержки необходимо выполнить несколько ключевых шагов. Во-первых, выбрать или разработать систему управления обращениями, которая поддерживает настройку различных календарей рабочего времени для каждой группы. Во-вторых, интегрировать эту систему со всеми каналами поддержки пользователей для сбора информации в едином формате. В-третьих, настроить автоматическое отслеживание времени обработки каждого этапа, учитывая только рабочие часы соответствующей группы. В-четвертых, создать единую панель мониторинга с возможностью фильтрации по регионам, типам обращений и другим ключевым параметрам. В-пятых, внедрить систему уведомлений для менеджеров при приближении к критическим значениям SLA. Также важно обеспечить возможность сбора обратной связи от пользователей и интеграции этих данных в систему мониторинга для комплексной оценки качества работы.
Да, чем шире охват учета в CMDB, тем сложнее оценить трудозатраты. С увеличением количества учитываемых конфигурационных единиц возрастает число привлекаемых к сопровождению специалистов, которые решают разные по ресурсоемкости задачи. Разные группы конфигурационных единиц (ИТ-системы, бизнес-приложения, технологические элементы бизнес-приложений, инфраструктура) обслуживают разные специалисты с различной стоимостью рабочего времени. Кроме того, структура информации и источники ее получения тоже различны для разных групп. Это делает необходимым детальную разбивку по группам и ролям для точной оценки трудозатрат. При широком охвате становится критически важным нормирование отдельных задач по сопровождению CMDB в разбивке по участвующим ролям и учету требований к компетенциям исполнителя.
При выборе средств автоматизации для ITSM процессов следует учитывать несколько ключевых аспектов. Главное - убедиться, что выбранное средство может реализовать требования к автоматизации процессов, а не наоборот, чтобы требования процессов не определялись возможностями конкретного инструмента. Необходимо провести тщательный анализ бизнес-требований и специфики работы организации до выбора системы. Также важно оценить масштабируемость решения, совместимость с существующей ИТ-инфраструктурой, качество технической поддержки поставщика, стоимость владения на протяжении всего жизненного цикла. Не менее критична оценка способности системы гибко адаптироваться к будущим изменениям процессов. Эффективная автоматизация должна поддерживать и усиливать бизнес-процессы, а не заставлять организацию полностью менять способ работы ради использования определенного программного продукта.
Оптимальная структура классификатора изменений должна быть матрично-иерархической. Это позволяет эффективно управлять разнообразием изменений без избыточного создания множества моделей. Структура классификатора включает следующие элементы: - Группировку по категориям: изменения могут быть сгруппированы по категориям в зависимости от типа (стандартные, нестандартные), уровня риска, специфики объекта изменения (ИТ-инфраструктура, сетевые компоненты, информационные системы). - Типовые порядки обработки: для каждой группы определены типовые порядки прохождения этапов, включая определение необходимых согласований, этапов выполнения, условий включения в релиз. - Параметризация по объектам: к каждой группе систем или направлений привязаны специфические параметры, такие как назначение координатора, список уполномоченных на согласование, обязательные результаты этапов. - Иерархия детализации: стандартные изменения могут иметь высокую степень детализации, включающую чёткие указания по этапам и исполнителям, тогда как для нестандартных изменений детализация фокусируется на ключевых этапах анализа и оценки. Пример такой структуры: - Для ИТ-инфраструктуры: общий типовой порядок обработки с опциональными этапами для работ, выполняемых в рабочей среде. - Для информационных систем: общий мастер-порядок с обязательным этапом приёмочного тестирования. - Дополнительная параметризация под конкретные системы или типы изменения (например, для критически важных систем – дополнительные этапы оценки влияния). Такой подход позволяет сократить количество полностью уникальных моделей, упростив процесс поддержки и адаптации классификатора к изменениям в ИТ-ландшафте.
Обеспечение учета затрат и доходов включает определение и контроль соблюдения правил учета затрат и доходов. Фактическая регистрация осуществляется в операционных процессах: управление конфигурациями, управление проектами, планирование и выполнение продаж, ведение договоров.
Процедура построения модели учета и аллокации ИТ-затрат тесно связана с управлением проектами и изменениями, поскольку правила учета и аллокации ложатся в основу реализации технических решений, которые затем внедряются через проекты и процессы управления изменениями.
Быструю реализацию улучшений в ITSM можно достичь через внедрение небольших, но эффективных изменений в рамках текущей работы, подобно подходу CSI (Continual Service Improvement). Как показывает пример, не требуются масштабные и длительные проекты для достижения значимых результатов - сокращение времени решения инцидентов на 40% за полгода было реализовано собственными силами в режиме текущей деятельности. Успешное внедрение включает в себя четкое определение проблемы, разработку простого и понятного решения, постепенное внедрение с учетом пользовательского опыта и постоянную обратную связь. Ключевые факторы успеха - фокус на решении конкретной задачи (в данном случае сокращение времени на сбор информации и маршрутизацию), простота реализации и внимание к удобству конечных пользователей, что приводит к естественному принятию новой системы.
Выявленные расхождения документируются в структурированном формате, включающем: идентификатор конфигурационного элемента, список несоответствующих атрибутов, описание реального состояния, причины расхождения (если установлены), рекомендации по исправлению, ответственных за устранение и сроки. Для автоматизации используется интеграция результатов с системами управления изменениями (например, Jira), чтобы создавать задачи на корректирующие действия. Документ должен быть доступен владельцам данных CMDB и процессным менеджерам для последующего анализа трендов.
Основные практики управления ИТ-услугами по ITIL 4 включают: управление инцидентами (минимизация негативного влияния инцидентов за счет скорейшего восстановления работы); управление запросами на обслуживание (выполнение предопределенных пользовательских запросов эффективным способом); мониторинг и управление событиями (систематическое наблюдение за услугами и их компонентами); сервис деск (обработка спроса на решение инцидентов и выполнение запросов, обеспечение единой точки входа); управление проблемами (уменьшение вероятности и влияния инцидентов через идентификацию причин). Эти практики совместно обеспечивают быстрое восстановление услуг при сбоях, эффективную обработку запросов, управление состоянием услуг и выявление ошибок в продуктах.
Пять ключевых факторов, определяющих поведение людей, — это личные качества, комплексы, знания, навыки и мотивация. Руководители имеют существенное влияние только на три из них: знания, навыки и мотивацию (на комплексы — в меньшей степени, а на личные качества — крайне слабо). Из трех указанных факторов руководители могут влиять на знания и навыки через обучение, что особенно важно для успешной реализации проектов, направленных на изменение поведения сотрудников.