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

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

25
авторов

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

100%
оригинальный контент
Если бизнес и ИТ не имеют общего видения, это может привести к серьезным проблемам. Во-первых, ИТ-подразделение может не понимать, на какие бизнес-цели ориентирован бизнес, что снижает эффективность предоставляемых услуг. Во-вторых, отсутствие общих целей приводит к несоответствию ожиданий: бизнес недоволен работой ИТ, а ИТ не осознает, что нужно улучшить. В-третьих, без четкого определения показателей и требований качество услуг становится субъективным. Все это влечет за собой снижение уровня доверия и превращает взаимодействие в формальное и конфликтное.
Потребности (Север) и желания (Запад) различаются по своей значимости и обязательности для клиента. Потребности - это базовые, необходимые условия, без которых услуга не будет считаться полезной или приемлемой. Например, для услуги такси необходимым является именно перемещение от точки А до точки Б. Желания же - это дополнительные элементы, которые при наличии повышают удовлетворённость, но их отсутствие не делает услугу непригодной. Например, вежливый водитель или приятная музыка в такси являются желаниями. Понимание этой разницы помогает правильно расставлять приоритеты в развитии сервиса: потребности должны быть обеспечены в первую очередь как основа, а желания могут быть использованы как дифференцирующие факторы для превосходства над конкурентами.
Агрегация метрик на разных уровнях управления осуществляется последовательно, начиная с нижних уровней. Например, начальник определенной функции на местном уровне оценивается по процессным метрикам своих подчиненных. После этого эти метрики агрегируются для оценки руководителя на следующем уровне (например, регионального руководителя). Региональные метрики, в свою очередь, агрегируются для оценки руководителя в головном офисе (HQ). Такая многоуровневая система позволяет отслеживать эффективность управления на всех уровнях. При этом важно, чтобы все метрики были приведены к сопоставимому формату (шкала от 0 до 1), что позволяет корректно комбинировать их через арифметическое среднее, геометрическое среднее, взвешенное среднее или по доле от целевых значений. Такой подход обеспечивает прозрачность и согласованность оценок на всех уровнях организации.
Понимание парадигмы ITSM критически важно для системных аналитиков и менеджеров, так как оно позволяет им эффективно проектировать и управлять комплексными ИТ-решениями в соответствии с бизнес-потребностями. Знание стандартов ITSM помогает правильно определить требования к системам, спланировать их жизненный цикл, обеспечить плавную интеграцию с существующими сервисами и процессами. Для менеджеров это знание необходимо для выстраивания стратегии развития ИТ-инфраструктуры, управления ресурсами и демонстрации бизнес-ценности ИТ-инвестиций. Это создаёт общую платформу взаимодействия между техническими специалистами и бизнес-руководителями.
Успех проекта зависит от взаимодействия разных ролей, потому что комплексные задачи требуют разнообразных навыков и подходов. Менеджер обеспечивает структуру и контроль, лидер поддерживает мотивацию и видение, а оперативные исполнители отвечают за детали реализации. Если все функции сосредоточены в одном человеке, это может привести к перегрузке и снижению качества как стратегических, так и оперативных решений. Взаимодополняемость ролей позволяет каждому участнику сфокусироваться на своей зоне ответственности, что повышает общую эффективность и устойчивость проекта к рискам. Пример строительства пирамиды в деловой игре подтверждает, что даже при наличии сильного менеджера необходимы другие участники для достижения максимального результата.
Система руководства ИТ по COBIT 5 отвечает за формирование политики и стратегии в области ИТ, определение целей и ожидаемых результатов, а также за контроль достижения этих результатов в интересах заинтересованных сторон. Она обеспечивает создание рамок, в которых действует система управления ИТ, и определяет, каким образом ИТ-ресурсы и процессы способствуют достижению целей бизнеса. Основные функции системы руководства включают оценку текущего состояния, определение направления развития и мониторинг результатов.
SIP сложно внедрить из-за необходимости серьезного пересмотра руководством приоритизации работ и принципов организации труда. Внедрение эффективной программы совершенствования услуг требует изменения корпоративной культуры и перестройки мышления управленческой команды в сторону фокуса на потребителе и постоянного улучшения. В реальности живая, функционирующая SIP встречается редко, даже реже, чем такие артефакты как каталог услуг, хотя именно SIP по своей сути должна являться главным элементом системы управления сервисами, обеспечивающим реальное улучшение качества услуг.
Согласно Business Continuity Institute Good Practice Guidelines 2010 (GPG), жизненный цикл системы управления непрерывностью бизнеса состоит из шести этапов: анализ организации, определение стратегии обеспечения непрерывности, разработка и внедрение планов обеспечения непрерывности, испытание и оценка планов, менеджмент программы управления непрерывностью бизнеса, внедрение управления непрерывностью бизнеса в организационную структуру. Каждый этап подробно описан в документе.
Структура сервисной поддержки ИТ-услуг включает несколько ключевых компонентов: уровни поддержки (первая, вторая, третья линия), системы управления инцидентами и запросами, базы знаний, процессы управления проблемами и изменениями, системы мониторинга и отчетности. Также в неё входят определенные роли и ответственности сотрудников, SLA-соглашения с клиентами, метрики оценки качества обслуживания. Эффективная структура поддержки обеспечивает быстрое реагирование на инциденты, проактивное решение проблем и постоянное улучшение качества предоставляемых услуг.
Стандарт ISO 31010 «Risk Management – Risk assessment techniques» подробно описывает метод анализа дерева отказов (FTA), предоставляя более развернутую информацию, чем другие источники. Этот стандарт не только объясняет теоретические основы метода, но и приводит конкретные примеры построения деревьев отказов с использованием булевой логики. В частности, в стандарте демонстрируется, как с помощью логических элементов («и», «или», «исключающее или», «не») можно представить различные пути возникновения конечного нежелательного события, создавая наглядную схему причинно-следственных связей, которая помогает в оценке рисков и принятии решений по их снижению.