Много лет я проектировала, внедряла и развивала крупные ИТ‑системы, а еще руководила командами аналитиков, разработчиков и IT‑проектами в целом.

Практически на любом этапе — от первичного обследования до опытной эксплуатации — команда может столкнуться с пассивным или активным сопротивлением. Если вовремя не сгладить углы, саботаж со стороны пользователей или руководства может заблокировать и разработку, и внедрение и свести на нет все усилия.

Мои самые ценные кейсы выросли из ошибок и срывов в работе с людьми. Именно факапы помогли мне создать работающие алгоритмы, которыми я делюсь, чтобы вы смогли избежать подобных граблей.

В статье рассмотрю:

• Как определить ключевых стейкхолдеров, способных навредить проекту?

• Как вернуть доверие, если предыдущие команды провалили автоматизацию?

• Как преодолеть сопротивление отделов с помощью перераспределения функций?

• Как распознать скрытые интересы и в каких случаях проект лучше вовремя закрыть?

1. Где искать сопротивление

В крупном проекте представителей заказчика много. Это могут быть и внешние пользователи системы, и разные группы сотрудников организации заказчика, их руководители и руководители компании. Невозможно одинаково внимательно следить за всеми стейкхолдерами, поэтому следует выделить тех, кто потенциально может повредить работам команды разработчиков.

Для выделения наиболее критичных удобно применять матрицу заинтересованных сторон (на рисунке — ЗСт) из Руководства к Своду знаний по бизнес‑анализу, BABOK Guide V3. Исходя из отношения к изменению, которое привнесет ИТ‑система, и влияния на процессы организации, выделим 5 групп (рисунок ниже).

К группам с высоким уровнем влияния (группы 1 и 2) мы относим:

• Лиц, принимающих решения (ЛПР): руководители и топ‑менеджеры, наделенные полномочиями подписывать акты, утверждать бюджеты и закрывать этапы.

• Предметных экспертов (SME, Subject‑Matter Expert): ключевые специалисты, обладающие уникальной экспертизой в бизнес‑процессах. Именно у них мы выясняем истинные потребности и «боли» компании.

• Технических специалистов: ИТ‑архитекторы, специалисты по информационной безопасности и администраторы смежных систем. С ними согласовываются технические решения, схемы интеграции и требования к безопасности.

К группам с низким уровнем влияния (группы 3 и 4) мы относим:

• Массовых (конечных) пользователей: линейных сотрудников, которым предстоит ежедневно выполнять рутинные операции в создаваемой системе.

• Смежных экспертов: представителей смежных подразделений, которые напрямую не работают в системе, но их процессы косвенно затронуты изменениями.

На ком сосредоточить внимание в первую очередь

В процессе управления рисками основной фокус всегда держится на группе 2 — «влиятельные противодействующие». Это наиболее опасная категория: у них есть административные ресурсы, авторитет и рычаги, чтобы заблокировать проект, затянуть приемку или перекрыть финансирование.

Однако нельзя полностью игнорировать и группу 3 — «мало влияющие противодействующие».

Когда сопротивление проявляет не единичный сотрудник, а целая группа или отдел, это сигнал о системной проблеме.

За коллективным саботажем почти всегда стоят веские причины — страх изменений, потеря контроля или нежелание переучиваться. И у организованного сопротивления рядовых сотрудников почти всегда есть явный или скрытый покровитель из группы влиятельных стейкхолдеров. Направляя или молча одобряя саботаж «снизу», такой покровитель пытается решить свои задачи чужими руками.

Как распознать сопротивление

Сопротивление не всегда выглядит как открытый конфликт. Чтобы вовремя заметить проблему, обращаем внимание на следующие сигналы:

1. Пассивное сопротивление (игнорирование)

• Молчание: игнорирование писем и сообщений в мессенджерах.

• Уклонение: нежелание отвечать на вопросы и регулярные пропуски встреч.

• Затягивание: бесконечное согласование даже простых вопросов.

2. Активное сопротивление (прямой саботаж)

• Сокрытие деталей: умалчивание важных нюансов процессов, которые критически влияют на результат.

• Критика без аргументов: эмоциональные фразы вроде «Это не сработает» или «У нас так не принято».

• «Итальянская забастовка»: откровенное игнорирование задач или их формальное выполнение «для галочки».

• Сплочение: скрытая или явная поддержка других саботажников.

3. Бюрократическое сопротивление (палки в колеса)

• Отказ от оформления: необоснованное затягивание подписи актов и сдачи этапов.

• Сюрпризы под дедлайн: внезапное появление новых «критически важных» требований прямо перед релизом.

• Раздувание мелочей: возведение незначительных недочетов в статус катастрофы и блокера проекта.

2. Причины противодействия и способы преодоления

Чтобы наше воздействие принесло положительный результат, а не навредило, полезно разобраться в причинах противодействия или бездействия. Вот основные причины сопротивления и возможные приёмы воздействия:

Негативный прошлый опыт

Суть проблемы

Компания уже несколько раз пыталась автоматизировать процесс, но безуспешно. Стейкхолдер потратил кучу времени на предыдущие команды, поэтому заранее уверен: у вас тоже ничего не получится.

Решение: соавторство

Если проект критически зависит от такого эксперта, его негатив можно переломить, сделав соавтором решения.

Кейс из практики

Ключевой эксперт компании (назовем его А.) отказался обсуждать с нами автоматизацию прогнозирования. Прошлая команда выслушала его идеи, проигнорировала их и ушла с проекта. А. не хотел повторно тратить время на подрядчиков.

Как мы переломили ситуацию:

1. Собрали контекст. Через коллег А. мы выяснили суть проблемы и его замысел.

2. Подготовили решение. Проработали концепцию с учетом идей А. и даже проконсультировались со сторонним экспертом.

3. Показали результат. На презентации А. увидел, что его задумку реально воплотить, воодушевился и включился в работу.

Итог: в соавторстве с экспертом мы доработали предложение, успешно защитили прототип перед руководством, разработали и запустили систему прогнозирования.

Страх потери контроля, влияния и неизвестность

Суть проблемы

Система автоматизирует то, что раньше вручную контролировал конкретный руководитель или ключевой сотрудник (назовем его B.). Человек боится неизвестности и задается двумя вопросами:

1. Смогу ли я управлять процессом в новых условиях?

2. Не потеряю ли я свою ценность и эксклюзивность для руководства, когда систему запустят?

Этот страх почти всегда возникает из‑за недостатка информации. Не понимая, как изменится работа, сотрудник выбирает простейшую стратегию — не связываться и блокировать изменения.

Решение: перепроектирование процессов

Покажем сотруднику его новое место в системе и поможем трансформировать его роль из «тушителя пожаров» в эффективного менеджера.

Кейс из практики

Мы автоматизировали отдел сбыта на пищевом предприятии. Диспетчеры работали круглосуточно, принимая и оформляя заказы. Руководитель отдела B. всячески саботировал внедрение. Оказалось, он опасался, что с уменьшением нагрузки на отдел снизится и его личная значимость в глазах руководства.

Как мы решили проблему:

1. Изменили бизнес‑процесс. Добавили в систему предварительные заявки с возможностью их корректировки и полностью отменили ночные смены диспетчеров.

2. Организовали переход. Совместно с B. разработали новые регламенты и провели обучение как для сотрудников, так и для клиентов предприятия.

3. Смягчили оптимизацию. Численный состав диспетчеров уменьшился без болезненных увольнений: часть людей перешли на другие позиции внутри компании, кто‑то ушел в декрет, а кто‑то выполнил давно задуманное — сменил профессию.

Итог: руководство высоко оценило грамотную реорганизацию процессов. И руководитель B., вместо потери статуса, доказал свою управленческую эффективность и получил повышение.

Нагрузка на команду в период внедрения: как не сжечь людей

Суть проблемы

Внедрение нового ПО — это всегда двойная нагрузка. Сотрудникам приходится осваивать неизвестный инструмент и перестраивать привычную работу, не останавливая «текучку». Руководитель подразделения закономерно опасается: показатели просядут, команда перегорит, а бизнес получит проблемы вместо пользы.

Решение: поэтапный запуск и грамотная фасилитация

Снять этот страх помогает не директивное насаждение, а совместная работа над сценарием перехода, где учтены риски каждой стороны.

Кейс из практики

Руководитель отдела С. категорически выступал против проекта. Его аргументация была железобетонной: люди просто не вытянут одновременно и оперативную работу, и процедуры внедрения.

Как мы решили проблему:

1. Собрали кросс‑функциональную встречу. Пригласили руководителей и заряженных специалистов из других подразделений, где также планировалось внедрение.

2. Перешли к поэтапному плану. Заранее подготовили черновик дорожной карты и предложили отказаться от формата «всё и сразу» в пользу пилотного запуска и внедрения волнами.

3. Использовали конструктивное окружение. На встрече активно выступали сторонники изменений из смежных отделов. Увидев, что процесс становится прозрачным, а его коллеги активно участвуют в дискуссии, С. понял, что риск оказаться в аутсайдерах выше, чем риск от изменений. Он включился в работу и помог доработать план под специфику своего отдела.

Итог: понятная стратегия, наглядные примеры коллег и детальная проработка рисков снизили уровень тревожности руководителя С. В процессе запуска из главного скептика он превратился в нашего активного сторонника.

Конфликт архитектурных ограничений, бизнес‑целей и правил

Суть проблемы

В реальной жизни процессы часто идут вразрез с официальными регламентами или требованиями информационной безопасности. Сотрудники привыкают «срезать углы» ради скорости и годами скрывают эти нарушения от руководства.

Автоматизация неизбежно делает все «серые» схемы и костыли прозрачными. Команда на местах начинает саботировать проект, потому что опасается разоблачения: никто не хочет, чтобы их привычные хаки и обходные пути всплыли наружу.

Решение: открытый диалог и поиск компромисса

Не наказываем за нарушения и не загоняем людей в жесткие рамки. Ищем первопричины обходных сценариев и усаживаем противоположные стороны за стол переговоров, перерабатываем правила под реальные задачи бизнеса. Иногда это очень непросто и не всегда получается с первого раза.

Кейс из практики

Классический клинч: цель службы безопасности — не допустить утечек и максимально ограничить доступы, а цель бизнеса — ускорить Time‑to‑Market. На практике жесткие ограничения ИБ тормозили работу, превращаясь в катастрофу в период отпусков. Сотрудники решали проблему неформально, а подсвечивать этот конфликт интересов при автоматизации никто не хотел — проще было тихо блокировать проект.

Как мы решили проблему:

1. Выявили реальную картину. Аналитики провели исследование, вскрыли скрытые противоречия и зафиксировали места, где регламенты безопасности критически тормозят процессы.

2. Провели серию сессий. Посадили за один стол экспертов от бизнеса и специалистов по ИБ, чтобы сформулировать единые правила игры.

3. Перестроили модель и процесс. Разработали новую матрицу прав доступа и скорректировали сам бизнес‑процесс: он стал устраивать бизнес по скорости и при этом полностью соответствовать требованиям ИБ.

Итог: поиск баланса потребовал времени — окончательные корректировки мы вносили уже на этапе опытной эксплуатации. Зато в результате компания получила не формальную систему «для галочки», а легальный, безопасный и действительно рабочий процесс.

Личные причины противодействия

Суть проблемы

Есть мнение, что на личные причины приходится около 10% всех случаев сопротивления. За ними почти всегда стоят скрытые интересы: финансовая выгода (например, связи с другим исполнителем или аффилированной компанией), страх потерять личный статус, контроль над ресурсами или серые схемы в процессах.

Решение: анализ и отказ от проекта

С этим типом противодействия бесполезно бороться стандартными методами — презентациями, обучением или фасилитацией. Если ключевой стейкхолдер лично заинтересован в том, чтобы проект не взлетел, сломать его сопротивление извне практически невозможно. Единственное правильное решение в такой ситуации — вовремя отказаться от проекта и не сжигать ресурсы команды.

Критерии, когда пора уходить и не тратить силы:

1. Расхождение в образе успеха. Совпадают ли представления клиента о результате с вашим видением, объективной реальностью и технологическими возможностями? Если цели заказчика противоречат цели проекта или здравому смыслу, проект обречен изначально.

2. Завышенные и недостижимые требования. Использует ли стейкхолдер объективные оценки или выдвигает заведомо невыполнимые показатели, чтобы гарантированно признать работу провальной?

3. Отсутствие гибкости. Готов ли заказчик к компромиссам и конструктивному диалогу? Если любое отклонение от его жестких условий воспринимается в штыки, это явный сигнал скрытого саботажа.

Итог: если ответы на эти вопросы показывают, что личный интерес стейкхолдера сильнее задач бизнеса, вовремя сказанное «нет» компанией‑исполнителем спасет бюджет, время и репутацию.

Противодействие с низким уровнем влияния

Суть проблемы

На первый взгляд, рядовые специалисты не способны заблокировать проект — у них просто нет административного ресурса. Однако их массовое сопротивление может легко парализовать любые изменения на этапе внедрения.

Причины сопротивления на этом уровне:

• Страх увольнения или перегруза: опасения, что новая система лишит их работы или повесит двойную нагрузку без доплат.

• Любые личные или системные факторы: от привычки к старым инструментам до банальной лени.

Главная особенность этого уровня: рядовые сотрудники практически никогда не саботируют процесс в одиночку. За их спиной почти всегда стоит кто‑то из влиятельных стейкхолдеров — например, руководитель подразделения, который негласно одобряет их поведение и покрывает задержки.

Кейс из практики

Внедряем новую ERP‑систему, автоматизируем отдел продаж. Операционисты или менеджеры должны перенести данные и начать работать по новому регламенту.

Вместо этого отдел устраивает молчаливую забастовку: задачи затягиваются, формально заполняются с ошибками, а на любые вопросы следует коллективный ответ: «Мы завалены текучкой, а ваша новая система не работает и тормозит процессы». Их непосредственный начальник на управляющем комитете разводит руками и защищает подчиненных: «Видите, люди зашиваются, решение сырое, мы сорвем основные KPI бизнеса».

Решение: переломить ситуацию

Пытаться уговорить саботажников или проводить для них очередные тренинги в такой ситуации бесполезно — они чувствуют безнаказанность под крылом своего руководителя.

Самый действенный способ разрушить групповое сопротивление — привлечь сторонних специалистов (аутсорс / аутстафф) и передать им часть функций.

Как это работает:

1. Заведение внешних ресурсов. Вы привлекаете подрядчиков или временных сотрудников для ввода данных, рутинных операций или работы в новой системе.

2. Лишение главного аргумента. Предлог «у нас нет времени и ресурсов» мгновенно обнуляется, так как задачи начинают выполняться сторонними силами.

3. Смена фокуса страха. Когда саботирующая группа видит, что процессы успешно идут без них, а сторонние исполнители легко справляются с новым инструментом, происходит психологический перелом.

Итог: страх «новых неудобных изменений» сменяется гораздо более сильным страхом потери работы и собственной незаменимости. Понимая, что их функции можно быстро перестроить или отдать на аутсорс, саботажники быстро теряют мотив для сопротивления и включаются в работу.

3. Заключение

Сопротивление изменениям при внедрении ИТ‑систем — это не аномалия, а естественная реакция людей на слом привычных процессов, потерю зоны комфорта или прозрачность, которую приносит автоматизация.

Главное правило при работе с негативом — не бороться с людьми, а убирать причины их сопротивления. Если научиться вовремя замечать тревожные маркеры, открыто обсуждать опасения стейкхолдеров и аргументировать пользу изменений на их языке, большинство «саботажников» можно превратить в союзников проекта. A там, где договориться невозможно, на помощь должны приходить административный ресурс спонсора и жесткая фиксация договоренностей.

Чек‑лист: алгоритм работы с противодействием стейкхолдеров

Чтобы системно отрабатывать сопротивление на проекте, используйте простой трёхшаговый алгоритм:

Шаг 1. Идентификация

• Отслеживаем признаки саботажа:

  • Пассивные: игнорирование писем, неявка на встречи, затягивание согласований, отсутствие вопросов.

  • Активные: критика без аргументов («Это не сработает»), формальное выполнение задач («итальянская забастовка»), неожиданные блокирующие требования в последний момент.

• Караулим неявное влияние: если сопротивление проявляет целый отдел или команда, ищем скрытого покровителя с высоким уровнем влияния (группа 2 по матрице).

• Оцениваем критичность: фиксируем, на каких именно этапах (обследование, согласование ТЗ, приемка, обучение) действия стейкхолдера создают блокеры.

Шаг 2. Диагностика

• Разделяем конструктив и эмоции: понимаем, что стоит за отторжением — реальные дыры в архитектуре/бизнес‑процессе или личные опасения.

• Выявляем истинный мотив:

  • Страх: потерять работу, показаться некомпетентным, не справиться с новой системой.

  • Потеря контроля: уход «монополии на знания» или разрушение привычных «серых» схем.

  • Прошлый негативный опыт: неудачные попытки внедрения другими командами в прошлом.

  • Перегрузка: необходимость делать текущую работу и одновременно участвовать в тестировании/внедрении.

• Проводим 1-to-1 встречи: обсуждайте опасения тет‑а‑тет, без протоколов и публичной огласки на общих совещаниях.

Шаг 3. Воздействие (работа с рисками)

• Перетягиваем на свою сторону: вовлекаем ключевых скептиков в рабочие группы. Когда человек сам участвует в проектировании решения, ему сложнее его критиковать.

• Показываем личную выгоду (WIFM — What’s in it for me?): объясняем, как система снимет с них рутину, уменьшит количество ошибок или ускорит ежедневную работу.

• Снижаем неопределенность: организуем понятное обучение, готовим удобные инструкции, закладываем время на адаптацию.

• Фиксируем границы: ведем протоколы встреч, фиксируем требования и критерии приемки «на берегу», чтобы исключить манипуляции в финале.

• Подключаем спонсора: если неконструктивный саботаж со стороны влиятельного стейкхолдера продолжается, эскалируем проблему на уровень бизнес‑заказчика проекта с языком цифр и рисков для бизнеса.

• Отказываемся от проекта: крайний случай, когда сопротивление ключевого стейкхолдера уже не риск, а свершившийся и неумолимый факт.

В моей практике хватало и ошибок, и жестких факапов. Зато именно они научили меня выстраивать коммуникацию и вывели рабочие алгоритмы. Делюсь своими кейсами, чтобы уберечь ваши проекты от похожих грабель.

А с какими сложными стейкхолдерами сталкивались вы? Напишите в комментариях!

Понимание причин сопротивления стейкхолдеров помогает аналитикам вовремя находить точки конфликта и не доводить проект до блокировки. Но важно уметь не только распознавать такие ситуации, но и управлять ими: выстраивать диалог с заказчиком, фиксировать договорённости и находить путь к сотрудничеству.

Если требования меняются, заказчик вмешивается в процесс, а команда теряет контроль над внедрением, помогут практические подходы к работе с такими рисками.

На открытых уроках разберём практические подходы к работе с изменениями и стейкхолдерами:

• 14 сентября, 19:00. «Анти‑паттерны управления: Почему «помощь» заказчиков убивает проекты и как вернуть контроль». Записаться

• 21 октября, 20:00. «Анатомия сопротивления: превращаем токсичных стейкхолдеров в союзников проекта». Записаться

• 22 октября, 20:00. «Управление изменениями требований». Записаться

Больше бесплатных уроков сентября смотрите в дайджесте.