Разговоры про импортозамещение софта давно перестали быть темой для кулуарных бесед айтишников. Сегодня это суровая реальность, в которой живут заводы, логистические центры и бухгалтерии по всей стране. Отключение западных вендоров и вполне конкретные требования регуляторов подтолкнули бизнес к решительным шагам, вот только решительность эта часто оборачивается настоящей драмой. Огромные предприятия, годами работавшие на SAP или самописных монстрах, кинулись переезжать на 1С ERP, ожидая, что будет «почти как раньше, только дешевле». Однако на деле всё чаще получается иначе: проект затягивается на годы, бюджет разбухает вдвое-втрое, а пользователи в цехах и офисах тихо, а потом и громко начинают ненавидеть новую систему. Почему же внедрение, которое в теории должно было стать спасением, до сих пор напоминает экстремальный стресс-тест для всего организма компании? Проблема, как оказалось, не в строчках программного кода, а в глубоком разрыве между тем, чего хочет заказчик, тем, что умеет методология, и тем, как живые люди воспринимают перемены на своих рабочих местах.
Почему кнопка «сделать как в старом софте» не работает
Когда гендиректор или собственник даёт отмашку на переход, первая мысль, которую транслирует команда внедрения со стороны заказчика, звучит примерно так: «Давайте просто воспроизведём всё, что было в нашей предыдущей системе, но уже на платформе 1С». На первый взгляд это кажется разумным — люди привыкли, процессы отлажены, зачем ломать то, что работает. Только вот «1С:ERP Управление предприятием» спроектирована совсем иначе. Она изначально строилась вокруг методологий MRP II, бережливого производства и теории ограничений, то есть она требует сквозного планирования, управления именно производственным расписанием, а не простой фиксации того, что уже случилось. Когда заказчик упорно требует перенести в новую систему собственные «исторически сложившиеся хитрости» — например, способ учёта брака, сложившийся ещё при ручном управлении, — начинается беда. Интегратор вынужден пилить типовой функционал, навешивая десятки, а то и сотни специфических доработок. В итоге архитектура превращается в лоскутное одеяло, которое страшно обновлять и которое падает при каждой серьёзной смене релиза.
Специалисты, много лет варящиеся в этой кухне, не устают повторять: ERP — это не просто софт, это жёсткая методическая дисциплина. Обозреватели TAdviser неоднократно обращали внимание, что вендор упрямо пытается обучить рынок методологии, но бизнес пока чаще покупает лицензии ради самого факта импортозамещения, а не ради управленческой эффективности. Интегратор Александр Смирнов, управляющий партнёр крупного внедренческого центра, в беседе с CNews выразился предельно конкретно: «Наше глубокое убеждение состоит в том, что заказчику в первую очередь нужна не автоматизация текущего хаоса, а постановка регулярного менеджмента на базе современных цифровых инструментов». И это не фигура речи. На реальных проектах в машиностроении и пищевой промышленности выживали и давали результат именно те предприятия, где высшее руководство оказалось готово перетряхнуть привычные процессы, а не просто перерисовать старые эксельки в новом интерфейсе.
Особенно болезненно этот конфликт проявляется на участке расчёта себестоимости. Если завод десятилетиями жил без нормальных технологических карт и мастер на глаз определял, сколько металла ушло в стружку, то включение строгого учёта по спецификациям вызывает панику. Бухгалтерия вдруг видит, как «плывёт» маржинальность, которая раньше скорее угадывалась. Винить в этом начинают, конечно же, программу, а не многолетний бардак. Сюда же добавляется проблема нормативно-справочной информации. Для многих справочник «Номенклатура» — это просто перечень наименований, а в ERP это многослойная структура с жёсткими реквизитами, от которых зависит всё планирование закупок и производства. Когда на этапе обследования поленились разобраться с классификацией видов номенклатуры или перепутали типы воспроизводства, машина начинает выдавать такие планы, что цеха встают. И здесь снова всплывает разрыв: руководитель проекта со стороны заказчика — часто административный менеджер, не нырявший в детали оперативного учёта, а линейный персонал, который эти детали знает как свои пять пальцев, к принятию архитектурных решений просто не допущен.
Люди, которые не просто не хотят, а активно сопротивляются
Технически выверенная система может провалиться в одно мгновение, если коллектив встречает её глухим, а иногда и откровенно злым сопротивлением. Раньше переход на западную ERP воспринимался многими как шаг вперёд, нечто статусное, открывавшее карьерные перспективы. Сейчас же переезд на 1С у заметной части сотрудников нередко ассоциируется с вынужденным удешевлением, шагом назад в стабильности и удобстве. И пусть это субъективно, но такой психологический фон создаёт идеальную среду для саботажа. Кладовщицы, которые двадцать лет вели свои тетрадочки и непрозрачные экселевские файлы, вдруг сталкиваются с тем, что программа требует закрывать каждую накладную день в день и не даёт менять цифры «задним числом» парой кликов. Для них это не просто смена софта, это потеря контроля над информацией, и с этой потерей они будут бороться всеми правдами и неправдами.
Эксперты по управлению изменениями давно подметили: люди воюют не с переменами как таковыми, а с насилием над собой. Известный бизнес-тренер Михаил Рыбаков на Executive.ru сформулировал это очень точно: «Люди не сопротивляются изменениям, они сопротивляются насилию над собой. Если перемены навязаны сверху без объяснения личной выгоды для каждого конкретного исполнителя, включается защитный механизм». Перенесите этот тезис на цех или склад. Кладовщик должен не просто услышать приказ «теперь работаем через терминал сбора данных», а увидеть, что это реально избавит его от вечерних переписываний сотен позиций в бумажные журналы. Мастер участка должен понять, что прозрачный учёт выработки в системе станет его бронежилетом перед несправедливыми обвинениями в недостаче. Пока эта личная выгода не проявлена, любой глюк или зависание сервера будет раздуваться до масштабов катастрофы и служить доказательством того, что «эта ваша 1С — полная ерунда».
Ситуацию сильно усугубляет то, что творится на этапе запуска. Интегратор, сдав систему в промышленную эксплуатацию, зачастую переключается на новый проект, а разъярённые пользователи остаются один на один с методистами, которые физически не успевают разгребать лавину обращений. Возникает эффект «брошенного ребёнка»: люди чувствуют себя покинутыми, и негатив закрепляется на уровне корпоративного фольклора на годы вперёд. Отдельная боль — разрыв в цифровой грамотности. У станков сейчас работает много опытнейших людей старше сорока пяти, чьи руки помнят каждый винтик, но чьи глаза панически мечутся по экрану с десятками полей и фильтров. Формальное обучение в переговорке, когда дяденька с проектором два часа показывает слайды, не работает вообще. Сотрудник возвращается на место и впадает в ступор. Наталья Гаркуша, практикующий эксперт по внедрению, на страницах VC.ru делилась наблюдением: «Самые провальные проекты я видела там, где заказчик экономил на обучении и создании ролевых инструкций. Сотрудник не должен думать, куда нажать, у него должна быть чёткая пошаговая памятка под его конкретную роль, написанная человеческим языком, а не техническим жаргоном». Если такой памятки нет, каждый второй будет тихо саботировать, продолжая считать всё в своём стареньком Excel, а в ERP заносить данные раз в месяц, в последний день, убивая саму идею единого информационного пространства.
Откуда берутся бесконечные доработки и тормоза
Чаще всего внедрение уходит в штопор из-за того, что бизнес искренне убеждён в своей абсолютной уникальности. Аргументы звучат железно: «У нас не типовая сборка, у нас сложнейшая оборонка», «Наша химия не влезает ни в какие стандарты». Доля истины в этом есть, но практика показывает, что в девяти случаях из десяти за пафосными речами об уникальности скрывается банальный управленческий непорядок. Отсутствуют внятные технологические карты, годами культивировалась лояльность к нарушению маршрутов, а схемы списания материалов больше напоминали чёрную магию, чем математику. Интегратор попадает в западню: он обязан объяснить, что тащить этот хаос в новую систему смерти подобно, но, отказывая в доработках, он рискует просто потерять контракт. Сергей Колесников, основатель одного из старейших внедренческих центров, на конференциях Infostart не раз вводил понятие «заказной неудовлетворённости» — это когда систему строят не так, как объективно нужно предприятию, а так, как хочет видеть конкретный менеджер со стороны заказчика, исходя из своих привычек, сформированных ещё в девяностые годы.
Рецепт от Колесникова жёсткий, но спасительный: любое изменение в коде должно быть намертво привязано к конкретному экономическому эффекту. Если представитель заказчика не может доказать, что отсутствие какой-нибудь «волшебной кнопки» приведёт к потере, скажем, пяти процентов маржи, доработка отправляется в мусорную корзину. Это выглядит радикально, но иначе проект превращается в бесконечный долгострой, где программисты пилят сотни форм, которыми никто не пользуется. Важно, что современная платформа 1С даёт мощные инструменты для адаптации без снятия с типовой поддержки — механизмы расширений и внешних отчётов, — но культура их использования на стороне клиентов до сих пор удручающе низкая. Всем хочется «вскрыть ядро» и переписать логику под себя, а потом годами мучиться с обновлениями.
Есть и совсем прозаическая сторона — железо и производительность. Требования нынешней 1С ERP к серверам и каналам связи в разы выше, чем у старых «семёрок». И когда систему на триста пользователей пытаются запустить на виртуализации, собранной на коленке, без грамотной настройки СУБД PostgreSQL, начинается ад. Отчёт формируется не пять секунд, а сорок минут, и ни о каком оперативном учёте речи уже не идёт. Люди перестают вносить данные сразу, откладывают на потом, и система превращается в архив запоздавших цифр. ИТ-директора крупных холдингов на страницах IT Manager откровенно рассказывали, как перенос тяжёлых вычислений, например расчёта потребности в материалах, в ночные фоновые задания и вдумчивая настройка кластера серверов способны кардинально изменить пользовательский опыт. Однако в горячке запуска об этих «мелочах» забывают, а все шишки летят в платформу, которую обвиняют в технологической отсталости, хотя корень зла — в желании сэкономить на современной инфраструктуре и грамотных инженерах. В итоге замкнутый круг: система тормозит, пользователи бесятся, данные искажаются, а проект репутационно тонет, утягивая за собой веру в само импортозамещение.
