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

Для начала разберемся с тем, что именно подразумевается под словом “саботаж”.

* Этимология слова саботаж. Французское происхождение: sabotage от слова sabot — «деревянный башмак, сабо».В XIX веке рабочие во Франции носили такие деревянные башмаки — сабо. По одной версии, когда они протестовали против машин и механизации, они бросали свои сабо в механизмы ткацких станков, чтобы заблокировать их работу. Отсюда — «ломать машины сабо» → «саботировать работу».

Таким образом, саботаж со стороны сотрудников - недовольство, частичное или невыполнений функций в новой системе, которое затрудняет процесс внедрения/оптимизации.

? Основные причины саботажа внедрения 1С

• ? Основные причины саботажа внедрения 1С

• Страх потери компетенций и контроля

• Недоверие к качеству новой системы

• Отсутствие участия в проекте и чувства влияния

• Неясная мотивация и польза для пользователя

• Плохая коммуникация со стороны проекта

• Изменение власти и ролей

• Фатальная перегрузка

Рассмотрим причины, проявления и способы решения по конкретным отделам:

1. Бухгалтерия и финансовый отдел

Типичные причины

• Потеря привычных ручных инструментов (Excel, проводки вручную).

• Недоверие к автоматическим проводкам и закрытиям месяца.

• Опасение за ошибки, которые невозможно «поправить руками».

• Чувство потери контроля над отчетностью.

Формы проявления

• Ведение параллельного учета «для себя».

• Отказ проверять документы в 1С («я в Excel всё вижу»).

• Задержка проведения документов «до конца месяца».

• Преуменьшение ошибок старой системы и акцент на мелких багах новой.

Антидот

• Подключение бухгалтера как владельца бизнес-процесса.

• Показ автоматических сверок и регламентных операций.

• Короткие кейсы: «как система уменьшает ручную сверку».

• Доступ к пилотной базе с реальными документами.

Примеры кейсов

Кейс 1. Секретные Excel

Когда в компании внедрили новую 1С, бухгалтеры продолжили вести свои любимые Excel-таблицы «для контроля». Никто открыто не возражал против системы, но все отчёты проверяли по старым файлам. Когда суммы в отчётах 1С начали отличаться, обвинили систему: «она считает неправильно». Через пару месяцев выяснилось, что база пуста — большинство документов вообще не проведено. Сотрудники не саботировали напрямую, они просто не верили, что машина может считать лучше их. Только когда директор потребовал закрывать месяц исключительно по 1С и назначил одного из бухгалтеров «куратором изменений», ситуация изменилась. Перепроверяли документы по несколько раз, тратили на это время, сроки проекта затягивались

Кейс 2. Ручные корректировки

Главный бухгалтер считала, что система не успевает за реальностью. Она вручную меняла проводки, чтобы всё «сходилось», уверяя, что это временно. Через полгода отчётность перестала сводиться: система формировала двойные проводки и странные сальдо. Оказалось, что все исправления вносились без логики и учета последствий. Когда консультанты предложили заблокировать возможность правок, бухгалтерия восприняла это как личное оскорбление. Пришлось неделями восстанавливать доверие — и к системе, и к людям.

Кейс 3. Пропавшие авансы

Когда бухгалтерия перешла в 1С:УХ, система стала автоматически напоминать об авансах, не закрытых первичкой. Один бухгалтер быстро понял, что уведомления видны руководству и портят статистику. Он стал «чистить» отчёт, создавая фиктивные документы списания, чтобы показатели выглядели идеально. На совещаниях хвалили: «Вот пример дисциплины». Но через полгода аудит показал, что по ряду контрагентов авансы висят без закрытия, а в базе — фиктивные акты. Когда сотрудника спросили, зачем, он ответил: «Так спокойнее — система не ругается». Это была не попытка обмана, а стремление избавиться от давления прозрачности. После инцидента компания пересмотрела KPI: важнее стало не “нулевые ошибки”, а достоверные данные.

2. Закупки и категорийные менеджеры

Типичные причины

• Уменьшение «гибкости»: нельзя править заказы, цены, поставщиков напрямую.

• Новые поля, статусы, маршруты согласования — «лишняя бюрократия».

• Боязнь потери скорости работы и KPI по обороту.

• Скрытый страх, что система покажет ошибки и дубли.

Формы проявления

• Создание заказов «в обход» системы (в письмах или Excel).

• Неполное заполнение карточек («система сама подтянет»).

• Жалобы на интерфейс и «неудобства» вместо конструктивных предложений.

Антидот

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

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

• Обратная связь через MVP-пилот.

Примеры кейсов

Кейс 1. Обход согласований

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

Кейс 2. Старый шаблон победил

В новой системе нужно было формировать заказы прямо из карточки поставщика, но закупщики продолжали пользоваться старым Excel-файлом. Они просто прикладывали файл к документу и считали, что этого достаточно. В BI-отчётах данные не собирались, зато «работа шла как обычно». Когда на совещании спросили, почему в системе нет реальных закупок, оказалось, что никто не использовал интерфейс. Формально все требования соблюдены — файлы есть, галочки стоят, но система пуста. Выделить ответственного  - владелец бп, выбор ответственного, поддержка руководства.

Кейс 3. Двойной заказ

В отделе закупок один из менеджеров опасался, что новая система не учтёт его срочную заявку. Чтобы «перестраховаться», он дублировал заказы: один вводил в 1С, а второй отправлял поставщику вручную по почте. Поставщик, конечно, отгрузил оба. Когда на склад пришло две партии вместо одной, начались поиски виноватых. Менеджер уверял, что «всё сделал правильно, просто система не подтвердила». По сути, он не доверял автоматическому процессу и решил «помочь» системе, создав хаос. После этого компания ввела оповещения о статусах заказов и короткое правило: если не пришло уведомление из 1С — значит, заказ не существует.

3. Склад и логистика

Типичные причины

• Страх, что система «всё видит» — кто недогрузил, кто не провёл.

• Неуверенность в навыках работы с компьютером.

• Опасение, что новые формы учёта приведут к «наказаниям» за несоответствия.

• Отсутствие обратной связи: они не видят, зачем им это нужно.

Формы проявления

• Задержка проведения документов, «забытые» перемещения.

• Отказ работать с терминалами сбора данных или сканерами.

• Заполнение документов задним числом.

• Формальные оправдания («не было связи», «не работает штрихкод»).

Антидот

• Простое обучение «на живых примерах» — показать, что система защищает их от штрафов.

• Введение понятных KPI: «все отгрузки проведены в день отгрузки».

• Мотивация не «за систему», а за упрощение жизни — меньше бумажек, меньше звонков.

Примеры кейсов

Кейс 1. Борьба с инвентаризацией

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

Кейс 2. Фиктивные перемещения

После внедрения нового блока учёта в 1С кладовщики должны были отражать все перемещения между зонами склада в системе, чтобы остатки совпадали с реальностью. Первое время всё шло гладко, пока не начались расхождения: ��овар «переезжал» из одной зоны в другую без фактического движения. Проверка показала, что сотрудники создавали фиктивные документы перемещения, чтобы «подогнать» цифры под нужные остатки и избежать расхождений при инвентаризации. Один из кладовщиков честно сказал: «Проще переместить в системе, чем искать, где реально лежит коробка». В итоге виртуальные ячейки стали полны несуществующих товаров, а реальные — без учёта. Когда система начала выдавать ошибки при отгрузке, стало ясно, что ручное исправление породило хаос. После этого внедрили фотофиксацию и сверку по штрихкодам, а за каждое расхождение стали начислять премию не за “нулевые ошибки”, а за своевременное выявление проблем. Только тогда учёт начал выправляться: люди поняли, что от них ждут не «идеальных остатков», а честных данных.

Кейс 3. Списали как брак

Когда склад стал работать в 1С:WMS, любое списание требовало указать причину. Один из кладовщиков быстро нашёл способ избавиться от несостыковок: он стал относить все ошибки в остатках на “брак”. Так отчётность оставалась чистой, а система не ругалась. Через несколько месяцев руководитель удивился: почему «брак» вырос в три раза, а фактически списаний нет? Проверка показала: под этим кодом прятались пересортицы, недостачи и всё, что угодно. На вопрос «зачем?» кладовщик ответил: «Система не ругается, значит, всё правильно». После этого убрали возможность выбирать причину без подтверждения ревизора.

Кейс 4. Кладовщица, которая плакала

На заводе внедряли 1С:WMS, чтобы избавиться от бумажных карточек и звонков «пришёл ли мой заказ». Раньше весь учёт велся вручную: на каждой полке лежала стопка карточек, по которым кладовщица выдавала материалы. Люди приходили ногами на склад, просили посмотреть, не появился ли нужный товар, и она звонила в бухгалтерию, сверяя остатки. Когда появилась система, всё должно было стать проще — остатки видны, заказы формируются заранее, ничего не теряется. Но для самой кладовщицы это стало катастрофой: она не понимала интерфейс, боялась ошибиться и плакала, говоря, что «теперь её работа никому не нужна». Коллеги пытались помочь, но каждый новый экран только усиливал панику. Через месяц на её место взяли новую девушку, которая не знала старых порядков и быстро разобралась с системой. Она не сравнивала «как было» — просто нажимала кнопки и радовалась, что не нужно считать по телефону. Старшая кладовщица всё-таки взяла себя в руки и стала незаменимым сотрудником.

4. Коммерческий отдел и руководители направлений

Типичные причины

• Система делает деятельность прозрачной.

• Опасение потери влияния: раньше можно было «решить на словах».

• Нежелание участвовать в тестировании и планёрках («это IT-шная история»).

Формы проявления

• Формальное согласование без чтения документов.

• Игнорирование регламентов («я всё равно по старому пути»).

• Снижение приоритета внедрения в своём отделе.

Антидот

• Привязка функционала к бизнес-целям: отчёты по марже, ABC-анализ, прогнозирование.

• Визуализация: «Теперь вы видите всю воронку по закупкам и остаткам».

• Личные выгоды — меньше ручных Excel-отчетов, быстрее закрытия.

Примеры кейсов

Кейс 1. Аналитика для галочки

Когда в компании внедрили BI-отчёты на базе 1С, отдел продаж формально согласился ими пользоваться, но на практике всё осталось по-старому. Менеджеры открывали отчёт только перед совещанием, делали скриншоты и переносили цифры в свои Excel-шаблоны. Потом считали показатели вручную — так, «как привыкли». Через пару месяцев начали жаловаться, что в 1С данные «не совпадают с реальностью». Проверка показала, что несоответствие возникало не в системе, а в их формулах. Для руководства это стало откровением: сопротивление не в недоверии к технике, а в привычке к собственным «истинным» цифрам. После серии демонстраций, где показали, как отчёты строятся из тех же источников, часть скепсиса исчезла. Но ещё долго при слове «BI» люди закатывали глаза — «опять эта аналитика для галочки»

Кейс 2. Задержка обновления планов

Планирование продаж в новой ERP требовало еженедельного обновления данных по каждому направлению. Руководители отделов вздохнули: «Ещё один регламент». Первые недели они честно вносили цифры, потом начали откладывать — «в пятницу некогда, сделаем в понедельник». Через месяц система показывала устаревшие планы, а отчёты по отклонениям теряли смысл. На совещаниях звучало: «Система неправильно считает», хотя она просто работала с данными двухнедельной давности. В итоге финансовый директор ввёл правило: план без даты обновления считается недействительным. После этого цифры в ERP начали обновляться вовремя, но недоверие к плановому блоку осталось. Сотрудники шептались: «Раньше хоть сами всё контролировали, теперь система нами командует».

Кейс 3. Игнорирование правил скидок

ERP не позволяла продавать ниже определённой маржи, но несколько менеджеров нашли способ обходить ограничение. Они писали директору в мессенджер и просили «ручное одобрение». Тот соглашался — клиент важнее. Через месяц аналитика показала падение прибыли. Когда выяснилось, что причина — в этих исключениях, директор впервые осознал, что саботаж может выглядеть как инициативность.

Кейс 4. План из головы

Когда в ERP внедрили модуль прогнозирования, менеджеры по направлениям должны были подтверждать планы через систему. Один из самых опытных специалистов отказался использовать расчёт — он доверял только себе. Он вносил в план «круглые цифры» и говорил: «Я рынок чувствую». Его показатели всегда «красиво сходились», пока BI не сравнил прогнозы с реальными данными — отклонение достигло 40%. Руководитель понял, что за внешним спокойствием скрывается саботаж эксперта, не желающего делиться властью с алгоритмом. После публичного разбора компания ввела “план-факт” как KPI, и система впервые стала инструментом, а не игрушкой аналитиков.

5. Руководители среднего звена

Типичные причины

• Опасение потерять «серую зону влияния» — система контролирует всё.

• Внедрение воспринимается как угроза их авторитету: «теперь и без меня видно».

• Боятся признать, что не до конца понимают процессы.

Формы проявления

• Замедление внедрения («нам нужно всё протестировать ещё раз»).

• Завуалированная критика проектной команды.

• Неформальные установки подчинённым: «делайте, как раньше».

Антидот

• Делать их амбассадорами изменений.

• Публичное признание вклада в успешное внедрение.

• Включение в комитет по управлению изменениями.

Примеры кейсов

Кейс 1. Саботаж через заботу

Начальник отдела закупок пожалел сотрудников: «Не мучайтесь с новой системой, я всё потом введу». Коллектив вздохнул с облегчением и перестал участвовать в пилоте. Через три месяца проект оказался в тупике — никто не понимал, как работать в ERP. Когда начальника вызвали к директору, он искренне удивился: «Я же хотел, чтобы людям было легче». Добрые намерения оказались самой мягкой формой саботажа.

Кейс 2. Затягивание сроков обучения

Руководители должны были пройти обучение по маршрутам согласования, но всё время переносили даты. «Сегодня не успею, завтра совещание, потом отчёты». Без них процессы не настраивались, и консультанты тестировали «вслепую». Когда система вышла в продуктив, начались сбои: документы зависали на несуществующих согласующих. Только после личного вмешательства генерального обучение стало обязательным — и процесс пошёл.

Кейс 3. Формальный контроль

Когда в компании внедрили новую систему согласования документов, начальники отделов получили роль утверждающих. Им нужно было проверять данные в карточках заказов и актов, прежде чем нажимать кнопку «Согласовать». Первые дни все старались — открывали документы, просматривали реквизиты, задавали вопросы. Но потом процесс стал рутиной: уведомлений было слишком много, и руководители начали утверждать всё подряд, не глядя. Они объясняли: «Я доверяю своим, если что — потом поправим». Через пару месяцев выяснилось, что половина проведённых документов содержала ошибки: пропущены счета, неверные контрагенты, перепутаны организации. Когда проектная команда подняла вопрос о дисциплине согласования, начальники искренне удивились — ведь «всё же утверждено вовремя». Только после того, как руководителю отдела показали реальные финансовые последствия этих “вовремя”, он понял, что формальный контроль — это не помощь проекту, а тонкая форма саботажа.

Кейс 4. Тест без теста

Начальник отдела настоял, что его процессы готовы к переходу в продуктив. Консультанты просили провести тестовую сессию, но он уверял: «Всё проверено». На деле никто не запускал тесты — документы были “просто проведены” без проверки связей. После запуска половина отчётов не формировалась. Руководитель объяснял, что хотел сэкономить время, «чтобы не задерживать проект». Это был классический случай «саботажа через ускорение»: желание показать лояльность обернулось парализацией. После этого в регламент добавили жёсткое правило: тест не проведён — переход невозможен, даже если директор торопит.

6. IT-отдел

Типичные причины

• Непризнание авторитета внешнего интегратора («мы сами знаем 1С лучше»).

• Страх утраты контроля над инфраструктурой.

• Перегрузка задачами и конфликт приоритетов.

Формы проявления

• Задержка интеграций, тестов, загрузок.

• Скептические комментарии: «Эта конфигурация не взлетит».

• Минимальное вовлечение в пользовательскую поддержку.

Антидот

• Совместное планирование и прозрачные границы ответственности.

• Признание их экспертизы в публичном формате.

• Включение в демо-сессии, где виден результат их работы.

Примеры кейсов

Кейс 1. Тихий бойкот интеграторов

Внутренние айтишники не хотели пускать внешних подрядчиков к серверу. Они тянули с выдачей доступов, объясняя всё «кибербезопасностью». Фактически защищали свою территорию: «Мы тут хозяева». В результате тестовая база так и не запустилась вовремя. Когда директор по IT ввёл чёткий регламент доступа и сделал совместные демо, напряжение спало. Сопротивление оказалось не в недоверии к проекту, а в страхе потерять значимость.

Кейс 2. Мы знаем лучше

IT-отдел решил, что система слишком часто обменивается данными с CRM, и самовольно изменил расписание обмена. Синхронизация стала раз в сутки, отчего остатки на сайте отставали на день. Продажи начали срывать заказы, но айтишники стояли на своём: «Так надёжнее». Когда нашли причину, они искренне удивились, что «маленькая правка» парализовала бизнес.

Кейс 3. Задержка обновлений

В компании IT-отдел отвечал за установку обновлений ERP-системы, но системный администратор решил, что «спешка вредна». Он ждал, пока «всё устаканится», и ставил патчи с недельным опозданием — чтобы «не сломать стабильность». На совещаниях уверял всех, что «так безопаснее», а проектная команда не сразу поняла, почему у пользователей не работает часть функций. Оказалось, что исправления ошибок и новые механизмы просто не установлены. Когда в очередной раз система зависла при закрытии периода, выяснилось: нужное обновление вышло две недели назад, но «руки не дошли». Внутри IT-отдела это считалось нормой — «лучше позже, чем с багами». После инцидента внедрили регламент: каждое обновление проходит тестирование в песочнице, но должно быть установлено в срок. Сопротивление исчезло, когда айтишники увидели, что прозрачный процесс не лишает их контроля, а наоборот снимает с них ответственность за последствия чужих задержек.

Кейс 4. Админ-арбитр

В одной компании системный администратор требовал, чтобы все изменения в 1С проходили через него лично — «для безопасности». Даже простое добавление пользователя или обновление справочника он задерживал на несколько дней. Когда пользователи жаловались, он спокойно отвечал: «Я решаю, когда безопасно». По сути, админ стал не хранителем, а арбитром — кто достоин работать в системе. Только после внутреннего аудита стало ясно, что именно он стал узким горлом проекта. Его перевели в зону поддержки, а администрирование разделили между несколькими специалистами. Система заработала мгновенно — оказалось, что главный риск был не технический, а человеческий.

7. Высшее руководство

Типичные причины

• Отсутствие вовлеченности: воспринимают внедрение как «технический проект».

• Недооценка роли коммуникации и лидерства изменений.

• Страх временных потерь эффективности.

Формы проявления

• Неучастие в коммуникации («пусть IT рассказывает»).

• Отсутствие примера использования 1С на уровне топов.

• Неявное разрешение саботажа снизу (через молчаливое одобрение).

Антидот

• Видимость вовлечённости: топы первыми используют отчёты из 1С.

• Публичное подтверждение обязательности работы в системе.

• Связка целей проекта с бизнес-результатами.

Примеры кейсов

Кейс 1. ERP? Это дело IT

Генеральный директор говорил, что поддерживает проект, но сам никогда не открывал систему. Все отчёты просил в PowerPoint, как раньше. Подчинённые быстро поняли сигнал: если шеф не пользуется ERP, и нам можно не спешить. Через полгода внедрение фактически остановилось. Только когда директор начал требовать отчёты именно из 1С, отделы начали работать по-новому.

Кейс 2. Неудобно на старте — отменяем

После запуска ERP выросло время закрытия месяца, и топ-менеджеры начали жаловаться. Директор не выдержал и сказал: «Возвращаем старую систему, пока не починят». Сотрудники восприняли это как разрешение не переходить на новое. Через неделю база опустела — никто не заходил. Проект пришлось перезапускать с нуля, уже с жёстким управлением изменениями. Иногда именно один эмоциональный шаг сверху обнуляет год подготовки.

Кейс 3  А как же я?

В одном крупном заводе по панельному домостроению внедряли ERP-систему. Завод был старой школы: руководителям за семьдесят, а финансовый директор каждый день вручную заносил все платежи в Excel — и гордился своей дисциплиной. Это был его ритуал, его власть над цифрами, его способ чувствовать, что без него ничего не работает. Когда он понял, что с новой системой данные будут подтягиваться автоматически, а таблицы — формироваться без его участия, лицо изменилось. Он стал резко критиковать консультантов, повышать голос на совещаниях, отказываться принимать этапы работ и демонстративно покидать встречи. Формально он говорил, что «система сырая», но на деле боролся за сохранение собственной значимости. Внедрение застопорилось, пока генеральный директор не вмешался лично. После откровенного разговора стало ясно, что за агрессией стоял страх — страх, что с запуском ERP его многолетняя привычка и уважение, основанное на ручной работе, исчезнут. Только после этого сопротивление прекратилось, но урок для команды остался: система меняет не только процессы, она трогает идентичность людей.

Кейс 4. Рапорт о внедрении

Когда внедрение 1С подошло к финалу, гендиректор потребовал красивый отчёт «о завершении проекта». Формально всё было готово: документы заведены, отчёты печатаются, пользователи обучены. Руководитель отдела автоматизации попытался возразить: «Мы не провели опытную эксплуатацию». Но директор настоял: «Главное — отчитаться». Пресс-релиз о «успешном запуске» вышел, а через неделю система встала из-за непроверенных обменов. Отделы вернулись к старым таблицам, и в кулуарах говорили: «Главное — галочка, а не работа». Этот случай стал классикой внутреннего саботажа сверху: когда успех важнее результата, проект обречён на второе внедрение.

Универсальные решения

Вовлекать сотрудников в проект — не информировать, а привлекать

? «Люди не сопротивляются изменениям, они сопротивляются тому, что их меняют без них.»

Коммуницировать через смысл, а не через инструкции

? «Если человек не понимает, зачем — он всегда найдет, почему нет.»

Обучение — не лекции, а практика на живых кейсах

? «Учиться нужно не системе, а тому, как она решает мою задачу.»

Лидерство и личный пример сверху

? «Если руководитель не работает в 1С — никто не будет.»

Быстрые победы и видимая польза

? «Ничто так не укрепляет веру в проект, как первая реальная экономия времени.»

Итог

Саботаж — не про лень, а про защиту.
Чтобы люди перестали защищаться, им нужно понимание, участие, уверенность, пример и результат.