Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
Эффективная интеграция управления запросами и доступом предполагает использование специализированных систем: передачу обработки запросов в Service Desk для организации рабочих процессов согласования и утверждения, а IDM-системы - для непосредственного предоставления и отзыва прав. Важно создать четкие интерфейсы между этими системами, чтобы обеспечить беспрепятственную передачу данных о запросах и статусах. Интеграция требует разработки коннекторов к управляемым ИТ-ресурсам и может потребовать привлечения внешних экспертов с опытом подобных проектов. Не рекомендуется строить отдельные конвейеры обработки запросов в IDM-системе, так как это приведет к дублированию функциональности и усложнению процесса.
Для измерения удовлетворенности сотрудников сервис деска можно применять несколько методов: регулярные анонимные опросы с частотой не реже двух раз в год, использование методики NPS с вопросом о вероятности рекомендации компании как места работы, неформальные коммуникации и случайные встречи, анализ больничных листов и отчетов об отсутствии на работе, проведение опросов через третьих лиц для обеспечения конфиденциальности, а также изучение мнений сотрудников на совещаниях и в рабочих группах. Важно учитывать атрибуты, такие как лидерство в команде, корпоративная культура, моральный дух, организационный климат и особенности трудовой деятельности.
При автоматизированном мониторинге критерии недоступности должны быть четко определены и детализированы. Это включает требования к периоду времени, когда услуга должна быть доступна, максимальную допустимую длительность простоя, после которой доступность считается нарушенной, и список событий, которые будут классифицироваться как факты недоступности. Правильное определение этих критериев необходимо для построения эффективной автоматизации учета доступности и обеспечения точности измерений.
Процесс учета доступности можно автоматизировать путем внедрения технических средств, способных фиксировать недоступность на основе событий без участия пользователя. Для этого необходимы четкие критерии недоступности, такие как временные рамки, в которые услуга должна быть доступна, допустимая продолжительность простоя и перечень событий, указывающих на недоступность. Автоматизация позволит собирать данные в отдельном журнале недоступности, затем объединять пересекающиеся периоды простоя и рассчитывать точные показатели доступности на основе сводной информации.
Типовое внедрение подразумевает использование не только типовой модели процесса, но и типового решения для совмещения этого процесса с конкретной компанией, учитывая её организационную и географическую структуру, компетенцию сотрудников, системы мотивации и корпоративные стандарты. Такой подход возможен только при наличии у компании характеристик, схожих с другой компанией, где процесс уже успешно внедрен, что позволяет осуществлять тиражирование. Типовое внедрение наиболее реалистично для групп компаний, состоящих из однотипных организаций со стандартной структурой, например, группы электростанций в составе Территориальной генерирующей компании. В таких случаях корпоративный стандарт уже разработан и утвержден, и задача сводится к его практической реализации на конкретном объекте.
Да, привлекать сторонних консультантов для проведения диагностики имеет смысл, при условии, что они работают в составе общей команды, а не полностью берут на себя процесс. Консультанты приносят воспроизводимые методики и свежий взгляд, что помогает и обогащает как диагностируемые команды, так и тех, кто проводит диагностику. Они могут выявить проблемы, на которые внутренние эксперты уже перестали обращать внимание. Однако полностью поручать диагностику сторонним консультантам не рекомендуется, так как это дорого для десятков команд, да и важно накапливать собственную экспертизу внутри организации.
Основная тема книги - построение каталога ИТ-услуг и организация Service Level Management (SLM) в ситуациях, когда ИТ-подразделение находится в составе компании или группы компаний. Книга подробно рассматривает методы формирования каталога ИТ-услуг, разделения его на каталог для заказчиков (Service Catalog) и каталог для пользователей (Service Request Catalog), а также рекомендации по внедрению ITSM. Авторы предлагают рассматривать бизнес-процессы предприятия как основной источник информации для формирования бизнес-ориентированного каталога ИТ-услуг.
Индикаторы оценки в стандарте ISO/IEC 15504 — это наблюдаемые свидетельства, подтверждающие выполнение определенных управленческих практик в процессе. Они служат основой для объективной оценки уровня зрелости процесса и могут быть представлены как документированными рабочими продуктами (планами, отчетами, протоколами), так и словесными подтверждениями от менеджеров и участников процесса. В COBIT 5 PAM эти индикаторы применяются для проверки наличия и стабильности выполнения ключевых управленческих действий: определения целей процесса, распределения ответственности, обеспечения ресурсов, измерения результатов и планирования улучшений. Чем больше подтвержденных индикаторов найдено, тем выше уровень зрелости процесса считается достигнутым.
Помимо технического резервирования (дублирование серверов, сетей), доступность повышается за счет: автоматизации процессов восстановления, внедрения систем предиктивной аналитики для выявления угроз, регулярного тестирования планов аварийного восстановления, оптимизации SLA с подрядчиками, обучения персонала и внедрения ИТ-сервис-менеджмента по ITIL. Ключевой аспект — снижение человеческого фактора через стандартизацию операций.
Сохранение работоспособности продукта на каждом этапе разработки позволяет команде своевременно тестировать гипотезы, получать обратную связь от пользователей и вносить коррективы. Если продукт на промежуточных этапах не функционирует целиком, невозможно оценить, насколько хорошо он соответствует реальным потребностям. Например, если создавать слона по частям (сначала ноги, потом уши), то невозможно проверить, как эти части будут работать вместе, пока не завершён весь процесс. В то время как начав с MVP (слонёнка), можно сразу увидеть, насколько он эффективен и какие улучшения необходимы.