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

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

25
авторов

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

100%
оригинальный контент
Автоматизация в управлении изменениями может быть реализована через интеграцию с конвейерами непрерывной интеграции и доставки (CI/CD). Если организация использует CI/CD, модель изменения должна учитывать эти процессы, чтобы автоматизировать этапы тестирования, развертывания и мониторинга. Это позволяет сократить время внедрения и повысить качество изменений за счёт предсказуемости и отсутствия ручных ошибок. Автоматизация особенно эффективна для регулярных, структурированных изменений.
В гибкой среде лучше делегировать команде задачи, которые способствуют развитию самоорганизации и распределения ответственности. Это включает проектирование архитектурных решений (с возможной консультативной ролью тимлида), установление стандартов кода через коллективное обсуждение, распределение задач между членами команды, проведение регулярных встреч планирования и ретроспектив, контроль соблюдения процессов. Эти действия помогают развивать команду как единую систему, где каждый член чувствует ответственность за общий результат, а не перекладывает ее на одного человека.
Если руководитель обнаруживает в RACI-матрице, что он является ответственным за выполнение задачи (A - Accountable), но механизмы контроля не определены, следует предпринять следующие шаги: 1. Сформулировать, какие конкретно инструменты контроля необходимы для данного вида деятельности (системы отчетности, регулярные проверки, программные инструменты мониторинга и т.д.). 2. Определить, кто сможет обеспечить эти механизмы (внутренние специалисты или внешние консультанты). 3. Обсудить необходимость создания указанных механизмов контроля до окончательного утверждения RACI-матрицы. 4. Зафиксировать в матрице или дополнительных документах перечень и порядок работы этих механизмов контроля. Важно, чтобы система контроля была не только описана, но и реально внедрена, так как ответственность без возможности контроля становится бессмысленной - руководитель будет нести ответственность за результат, на который фактически не может повлиять.
После участия в деловой игре важно сформулировать конкретные выводы, которые можно применить в реальной работе. Следует определить, какие стратегии оказались эффективными, а какие привели к неудаче, как улучшить взаимодействие между коллегами и как принимать более взвешенные решения в условиях неопределенности. Эти выводы должны быть четкими и измеримыми, чтобы их можно было внедрить в повседневную практику и оценить их влияние на реальные результаты.
Раннее информирование о назначении и принципах аллокации ИТ-затрат важно по нескольким причинам. Во-первых, сотрудники, чью работу будут оценивать на основе результатов аллокации, могут не принять изменения с готовностью, поэтому дача времени на адаптацию снижает сопротивление. Во-вторых, раннее вовлечение сотрудников позволяет учесть их замечания и внести корректировки в аллокационную модель до того, как это станет слишком затратно. Это способствует более гладкому внедрению системы и повышает ее точность и приемлемость для всех участников процесса, так как учитываются нюансы конкретных подразделений.
Положительный опыт взаимодействия с поставщиком услуг запоминается за счет неожиданности и приятной детали. Когда поставщик превосходит сложившиеся ожидания клиента, даже в небольшой мелочи, это вызывает положительные эмоции. Во-первых, неожиданность самого факта того, что клиент получает что-то дополнительное без дополнительной оплаты, удивляет в положительную сторону. Во-вторых, сама по себе дополнительная услуга или бонус («конфетка») доставляет радость, потому что она приятна и добавляет ценность к основному сервису.
В DevOps экспериментирование интегрируется в процесс постоянного совершенствования как ключевая деятельность для внедрения и развития методов обучения на ошибках. Это означает, что команда регулярно проводит небольшие эксперименты, чтобы проверить новые идеи, процессы или технологии в контролируемой среде перед их широким внедрением. Подход основывается на жизненном правиле — делать чаще то, что получается плохо, чтобы целенаправленно улучшать слабые места. Экспериментирование также подразумевает измерение результатов каждого эксперимента, анализ причин успеха или неудачи и систематическое распространение полученных знаний по всей организации. Такая практика создаёт культуру, где ошибки воспринимаются не как неудачи, а как возможности для обучения и роста, что значительно ускоряет процесс улучшения как отдельных продуктов, так и внутренних процессов компании.
Внешняя поддержка первой линии часто неэффективна в небольших организациях по нескольким причинам: персонал внешней компании имеет ограниченное знание специфики внутренних бизнес-процессов и ИТ-инфраструктуры, что приводит к низкой скорости решения проблем. Пользователи, привыкшие к быстрому и персональному обслуживанию от знакомых коллег, могут негативно реагировать на общение с незнакомыми людьми, которые не могут немедленно решить их проблемы. Кроме того, внедрение внешней поддержки может потребовать значительных временных затрат на настройку процессов и обучение внешних специалистов. В условиях небольшого объема обращений внешняя поддержка часто становится экономически нецелесообразной по сравнению с внутренней организацией поддержки.
ITIL рекомендует формулировать требования к срокам через конкретные даты и оценку влияния на бизнес. Например, вместо «это срочно» бизнес должен указать: «изменение нужно внедрить до 15 сентября, иначе будет потеряно 100 клиентов». Такой подход устраняет субъективность и позволяет ИТ-команде спланировать загрузку. Для emergency-изменений сроки определяются критичностью инцидента: если сервис недоступен, решение нужно «до восстановления сервиса», что фиксируется в метриках времени восстановления (MTTR).
Для встраивания понимания бизнес-ценности необходимо создать процессы и метрики, которые напрямую связывают ИТ-услуги с бизнес-результатами. Следует проводить обучение сотрудников на примерах конкретных бизнес-сценариев, как их работа влияет на конечных пользователей и бизнес-процессы. Регулярные совместные встречи с бизнес-заказчиками, разработка совместных KPI, которые измеряют не только технические показатели, но и бизнес-результаты, а также внедрение механизма сбора и анализа обратной связи от конечных пользователей помогут закрепить понимание бизнес-ценности в организации.