Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
Управление рисками присутствует в следующих процессах ITIL: 1. В группе процессов проектирования услуг - через управление доступностью, мощностями, непрерывностью и информационной безопасностью, где требуется анализ угроз и внедрение контрмер. 2. В управлении проблемами, особенно в проактивной его части, направленной на предотвращение инцидентов. 3. В постоянном совершенствовании услуг (CSI), где деятельность по улучшению часто приводит к идентификации рисков, а идентифицированные риски запускают новые циклы улучшений. 4. В управлении изменениями и релизами. 5. В управлении портфелем услуг. Все эти процессы содержат элементы идентификации, анализа и управления рисками, что делает управление рисками сквозной практикой в рамках ITIL.
Ограничение количества задач в работе (WIP) играет ключевую роль в методе канбан, так как предотвращает перегрузку участников и позволяет сосредоточиться на завершении текущих задач перед началом новых. WIP-лимиты помогают выявить узкие места в процессе работы, так как когда задачи начинают накапливаться на определённом этапе, это указывает на проблему, требующую решения. Также ограничение WIP способствует улучшению потока работы, уменьшению времени выполнения задач и повышению общей эффективности команды. Внедрение разумных WIP-лимитов является важной частью создания вытягивающей системы, где работа берётся на выполнение только когда есть свободные ресурсы.
Помимо общих управленческих компетенций (планирование, делегирование, контроль), менеджер процесса должен обладать: пониманием методологий процессного управления (BPMN, методологии моделирования процессов), навыками анализа и оптимизации процессов, умением выстраивать коммуникации между разными подразделениями, способностью работать в условиях ограниченного административного влияния, пониманием взаимосвязей между процессами и бизнес-целями компании, знанием метрик и KPI процессов. Эти специфические требования выделяют процессного менеджера среди других управленческих ролей.
Три основные причины сложности: 1) Противоречие между менеджерами и лидерами - традиционные менеджеры обучены работать по установленным процессам с фиксированными KPI, тогда как для успешного изменения необходимы лидеры, способные работать в условиях неопределенности и риска, создавать привлекательную картину будущего и увлекать сотрудников этой идеей. 2) Индивидуальное сопротивление сотрудников - преобразования нарушают привычный и комфортный порядок работы, вызывая чувство запутанности и потери ценности у сотрудников, которые стремятся вернуться к прежним, уже отработанным практикам. 3) Сопротивление организации как системы - крупные организации обладают инерцией, поддерживающей текущий порядок, снижающей ощущение срочности изменений, имеющей сложные коммуникации, не поощряющей риски и часто испытывающие нехватку ресурсов (трудовых, финансовых, временных, волевых).
Восемь шагов модели Джона Коттера для успешных изменений: 1) Создание ощущения срочности; 2) Создание коалиции; 3) Разработка видения и стратегии; 4) Коммуницирование видения; 5) Старт преобразований на всех фронтах; 6) Создание быстрых побед; 7) Консолидация и усиление изменений; 8) Закрепление изменений. Каждый этап играет важную роль в процессе трансформации организации.
Для управления техническим долгом необходимо регулярно резервировать время и ресурсы команды на его выявление и продуктивное снижение. Следует работать над принятием стратегических архитектурных решений и применять антихрупкие паттерны построения приложений. Технический долг неизбежен, но важно, чтобы он возникал вследствие осознанных решений. Непродуманный технический долг снижает производительность, увеличивает количество дефектов, ухудшает тестирование и мешает мониторингу системы.
Тема резервирования и восстановления данных является хорошей начальной точкой для ввода процесса SLM, потому что: - Эта тема хорошо понятна заказчикам, которые могут легко участвовать в обсуждении требований. - Вопросы по резервному копированию уже достаточно проработаны в отрасли, существуют четкие критерии для определения требований. - Требования к резервированию и восстановлению напрямую влияют на бизнес-процессы и безопасность данных, что делает их приоритетными. - Наличие работоспособной системы резервного копирования и восстановления данных значительно снижает риски, связанные с человеческими ошибками, которые чаще всего становятся причиной повреждения данных. - Успешная реализация этого аспекта создает основу для дальнейшего расширения SLM на другие области.
Ошибки в управлении изменениями, приведшие к кризису, включают недостаточное внимание к передаче знаний и умений по поддержке новых систем собственным специалистам после реализации масштабного проекта изменения производственной системы. Не была обеспечена должная синхронизация изменений в клиентском приложении и производственной системе, несмотря на их плотную интеграцию. Изменения вводились без учета реальных возможностей команд поддержки в условиях ограниченных ресурсов. Также не был проведен адекватный анализ рисков и потенциального влияния изменений на эксплуатационную надежность систем. Недостаточная коммуникация между командами привела к тому, что каждая команда сосредоточилась на своих задачах, не учитывая влияние своих действий на соседние области.
Автоматизация играет ключевую роль в процессе обработки запросов технической поддержки, позволяя существенно сократить временные затраты на несколько этапов. Программа автоматически собирает техническую информацию от пользователя через систему контекстно-зависимых вопросов, классифицирует запрос по соответствующей ИТ-услуге и маршрутизирует его к нужной группе специалистов. Это устраняет необходимость ручного перенаправления запросов, минимизирует ошибки классификации и ускоряет начало работы над инцидентом. В результате автоматизация обеспечивает более быстрое и точное обслуживание, что подтверждается снижением среднего времени решения инцидентов на 40% за полгода при достижении 90% использования новой системы.
Приоритет инцидента определяется на основе информации, полученной на этапе классификации, включая влияние инцидента на услуги, связанные конфигурационные единицы, уровень обслуживания (SLA) по затронутым услугам и другие релевантные факторы. Информация о влиянии инцидента и соответствующих SLA позволяет более точно определить, какой инцидент требует немедленного внимания, чтобы минимизировать негативные последствия для пользователей. Приоритет может корректироваться в ходе обработки инцидента при изменении обстоятельств, например, при приближении установленного срока восстановления услуги в SLA.