Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего.
Только сведения от консультантов и тренеров Cleverics.
Только сведения от консультантов и тренеров Cleverics.
6160+
вопросов и ответов
25
авторов
440+
источников
100%
оригинальный контент
Использование традиционного подхода к визуализации деления задач на части приводит к созданию изолированных компонентов, которые не формируют целостный продукт. Например, если рассматривать слона как набор отдельных частей (уха, ноги, хвоста), то на промежуточных этапах невозможно проверить работоспособность системы в целом. Это увеличивает риск того, что компоненты не будут корректно взаимодействовать, а также делает процесс разработки негибким и трудноадаптивным к изменениям. Кроме того, такой подход затрудняет получение обратной связи от пользователей и выявление критических ошибок на ранних этапах.
Учет связей между учитываемыми элементами важен, потому что позволяет понять, как изменения в одном компоненте ИТ-системы влияют на другие элементы и конечные услуги. Это необходимо для предотвращения нежелательных последствий изменений, анализа рисков и поддержания стабильности предоставляемых сервисов. Если такие связи не учитываются, система управления теряет свою функциональность и превращается в простой справочник активов.
Согласования часто превращаются в длинные цепочки из-за необходимости вовлекать различных заинтересованных лиц для минимизации рисков и обеспечения соответствия регламентам. Например, в цепочку могут входить руководители сотрудников, владельцы запрошенных ресурсов, представители службы безопасности. Дополнительно осложняет ситуацию наличие заместителей у руководителей, необходимость инициировать дополнительные согласования каждому третьему участнику для принятия окончательного решения, а также необходимость повторно напоминать о предстоящем согласовании. Это создает сложную структуру, где каждый этап зависит от нескольких участников, что увеличивает время и сложность всего процесса.
Управление процессом приоритизации инцидентов требует понимания того, что привычные критерии влияния и срочности больше не являются основанием для определения приоритета. Вместо этого необходима более сложная система, учитывающая бизнес-ценность услуги для организации. Повышение приоритета следует использовать как инструмент управления с осторожностью, так как это может привести к неприятным сюрпризам и нарушению баланса ресурсов. Для эффективной приоритизации важно: установить четкие критерии, основанные на бизнес-требованиях; внедрить систему автоматического определения приоритетов на основе этих критериев; регулярно пересматривать и корректировать приоритеты в соответствии с изменяющимися бизнес-потребностями; обучать персонал правилам приоритизации и ее важности для бизнеса. Правильная приоритизация гарантирует, что критически важные для бизнеса инциденты будут разрешаться первыми.
В тексте предлагаются две модели организации управления изменениями. Первый вариант - запрет совмещения ролей координатора и менеджера изменений, причем менеджер должен быть на уровне руководства, отвечающего за эксплуатацию ИТ-систем в целом, например заместитель начальника по эксплуатации. Второй вариант - назначение выделенного специалиста уровня непосредственного подчинения начальнику по эксплуатации, который по должностной инструкции отвечает исключительно за управление изменениями/релизами без совмещения с другими обязанностями. Первый вариант рассматривается как настоятельно рекомендованный минимум, второй - как более оптимальный, но требующий большей организационной подготовки
Согласно тексту, окончательное решение о приоритетах ИТ-изменений должно принимать бизнес-заказчик. ИТ-департамент выступает исполнителем, а владелец бизнес-требований несет ответственность за определение того, какие изменения имеют наибольшую ценность для бизнеса и должны быть реализованы в первую очередь. Однако возникает сложность, когда различные бизнес-подразделения конкурируют за одни и те же ИТ-ресурсы, поскольку каждый бизнес-заказчик отстаивает приоритетность своих задач.
Правила регистрации инцидентов должны основываться на четком определении нормальной работы услуги и согласованных уровней качества. Нужно определить, какие отклонения от нормы требуют немедленного вмешательства, а какие могут обрабатываться в плановом порядке. Критерии регистрации могут включать как технические параметры, так и субъективные факторы, например, недовольство пользователей. Важно, чтобы ответственные лица понимали, при каких условиях регистрировать инцидент, и имели четкий алгоритм принятия решений. Например, руководство ITIL 4 предлагает использовать такие критерии, как «пользователь несчастлив?», чтобы определить, стоит ли классифицировать ситуацию как инцидент.
Сдвиг парадигмы означает глубокое изменение управленческих принципов и организационной культуры, а не простое внедрение новых инструментов. Например, переход от управления по срокам к управлению по потоку требует пересмотра ролей, метрик и подходов к принятию решений. Это затрагивает основы взаимодействия бизнеса и ИТ, а также меняет восприятие ответственности внутри команд.
Признаками успешного внедрения процесса управления проблемами в компании являются сокращение количества повторных инцидентов, улучшение коммуникации внутри команд, четкое распределение ответственности, повышение скорости выявления и устранения причин проблем, а также осознанное включение организационных вопросов в процесс управления. Компания начинает фокусироваться не только на оперативном устранении сбоев, но и на системной работе по предотвращению их возникновения, что свидетельствует о переходе на более высокий уровень зрелости управления.
WIP-лимиты (Work in Progress Limits) оказывают значительное влияние на сокращение Time to Market, ограничивая количество задач, одновременно находящихся в работе. Это предотвращает перегрузку команды, уменьшает контекстные переключения и позволяет сосредоточиться на завершении текущих задач вместо их бесконечного запуска. Когда команда не пытается сделать всё сразу, но фокусируется на ограниченном количестве задач, циклическое время каждой задачи существенно сокращается. Например, в деловой игре 'Проект Феникс' внедрение WIP-лимитов и упорядочение потока работы позволили снизить Time to Market с 25 минут до 40 секунд - 1,5 минуты. WIP-лимиты также делают проблемы видимыми, так как перегрузка и узкие места становятся очевидными, что позволяет оперативно их устранять.