Проблемное внедрение 1С:ERP: как вернуть проект в управляемое состояние
Назад
Я, Ольга Васильева, основатель и генеральный директор ГК «Формула», специализируюсь на проектах цифровой трансформации и внедрения корпоративных систем управления. На практике я не раз сталкивалась с ситуациями, когда внедрение 1С:ERP не давало бизнесу ожидаемого результата. В этой публикации о том, что делать компании в такой ситуации и какие варианты выхода из нее действительно работают.
Бывает так: в автоматизацию уже вложены деньги, время и силы команды, а рабочей системы все равно нет. Сроки сдвигаются, доработок становится все больше, подрядчик обещает закрыть вопросы «на следующем этапе», но в повседневной работе 1С:ERP так и не становится рабочим инструментом ни для производства, ни для финансов, ни для управленческих решений.
За годы работы с 1С:ERP я не раз сталкивалась с такими ситуациями. И почти всегда проблема была не в одной неудачной настройке и не в одном ошибочном решении. Неудачное внедрение обычно складывается из нескольких просчетов сразу: проект стартовал без ясных целей, требования были описаны поверхностно, бизнес слишком поздно включился в процесс, а система постепенно обросла доработками, которые не усилили управление, а только усложнили работу и обслуживание системы.
На мой взгляд, в такой момент самая опасная ошибка — продолжать «дожимать» проект. Когда компания месяцами живет в режиме бесконечных исправлений, она часто теряет из виду главный вопрос: помогает ли система управлять бизнесом или просто потребляет еще больше ресурсов.
Почему внедрение заходит в тупик
Внедрение 1С:ERP редко не взлетает из-за одного фактора. Чаще всего это цепочка решений, которые по отдельности кажутся незначительными, а вместе дают плохой результат.
Одна из типичных причин — слишком быстрый переход к доработкам. Компания еще не договорилась о базовой логике процессов, но уже начинает программировать будущую систему. В итоге автоматизируется не порядок, а текущий хаос.
Вторая причина — попытка «учесть все сразу». В проект закладывают десятки пожеланий, исключений, частных сценариев и исторически сложившихся привычек. Система становится все сложнее, а прозрачности и управляемости не прибавляется.
Третья проблема — слабое участие бизнеса. Я много раз видела, как внедрение 1С:ERP-проекта фактически отдают на сторону подрядчику и внутренней ИТ-команде, а руководство подключается только на этапах эскалации. Это почти всегда плохой сценарий. 1С:ERP — не просто технический продукт. Это инструмент управления. Если первые лица не определили, какие решения бизнес хочет принимать на основе системы, внедрение быстро начинает жить отдельно от реальных задач предприятия.
Есть и еще одна распространенная ошибка: в новую систему переносят старую лоскутную логику. Таблицы, ручные схемы, неформальные согласования, дублирующие справочники, разные трактовки одного и того же показателя — все это просто переезжает в 1С:ERP в более дорогой форме. Внешне компания получает современную систему, а по сути — тот же беспорядок, только теперь уже внутри сложной цифровой системы.
В какой момент нужен аудит проекта
Обычно к этому вопросу приходят не в начале, а тогда, когда напряжение уже чувствуют все участники.
Руководство не может получить понятный ответ, когда проект даст результат. Пользователи говорят, что по-старому работать быстрее и надежнее. Подрядчик объясняет задержки сложностью процессов. Внутренняя команда занята согласованиями, обходными схемами и ручной перепроверкой данных.
Для меня есть несколько особенно показательных сигналов.
Первый — внедрение длится заметно дольше плана, а бизнес-эффект так и не появился.
Второй — система формально запущена, но ключевые операции по-прежнему ведутся в Excel, переписках и отдельных файлах.
Третий — цифры в отчетах вызывают сомнения, и их приходится регулярно сверять вручную.
Четвертый — никто не может внятно объяснить, почему система устроена именно так, какие решения были приняты по ходу проекта и где заканчиваются реальные требования бизнеса, а где начинаются компромиссы.
В такой ситуации я бы не советовала продолжать движение на автомате. Сначала нужен разбор: что именно не работает, почему это произошло и можно ли исправить ситуацию без полного перезапуска.
Что дает аудит — и когда он действительно нужен
Здесь важно сказать прямо: аудит не является универсальным ответом на все проблемы. Иногда он действительно нужен. Иногда нет.
Если компания зашла в тупик, внешний аудит может быть полезен как способ получить независимую картину. Пока проект находится внутри ежедневной рутины, у каждой стороны обычно своя версия происходящего. Подрядчик считает, что сделал все возможное. Пользователи уверены, что система неудобна. Руководители видят только последствия: задержки, конфликты, рост бюджета, ошибки в данных.
Объективный анализ позволяет убрать эмоции и собрать факты. Он помогает понять, где проблема действительно в настройках системы, где — в архитектуре решения, где — в управлении проектом, а где — в самих бизнес-процессах компании.
Но я бы не стала подавать аудит как единственный правильный путь. На практике варианты бывают разными. Иногда достаточно собрать сильную внутреннюю рабочую группу и заново зафиксировать требования. Иногда разумнее заменить подрядчика, чем пытаться бесконечно исправлять его подход. Иногда нужно пересобрать только один проблемный контур, а не всю систему целиком. А в некоторых случаях становится ясно, что дешевле остановиться, чем продолжать инвестировать в решение, которое изначально построено на кривой логике.
Ценность такого разбора — не в самом факте проверки, а в получении ясного ответа: что можно исправить, а что лучше переделать. Компании нужен не красивый отчет и не список виноватых. Ей нужен понятный ответ: что можно исправить, что лучше переделать, а от чего стоит отказаться.
На что я бы смотрела в первую очередь
Когда ко мне попадает проблемный 1С:ERP-проект, я прежде всего смотрю не на отдельные ошибки в системе, а на более базовые вещи.
Во-первых, есть ли у проекта понятная управленческая цель. Не список функций, не перечень модулей и не набор пожеланий подразделений, а четкий ответ на вопрос: что именно бизнес хочет изменить с помощью 1С:ERP.
Во-вторых, соответствует ли архитектура системы реальным процессам предприятия. Если модель в ERP живет отдельно от фактической работы производства, продаж, закупок или финансового блока, система неизбежно начнет буксовать.
В-третьих, кто реально управляет проектом. Если нет сильного заказчика внутри бизнеса, который имеет полномочия принимать решения, подрядчик почти всегда начинает подстраивать проект под компромиссы, а не под результат.
В-четвертых, как устроены данные и ответственность. Очень часто система страдает не потому, что она плохо настроена, а потому, что в компании нет договоренности, кто отвечает за нормативно-справочную информацию, правила учета, маршруты согласования и качество данных.
И, наконец, я всегда смотрю на пользователей. Если сотрудники формально прошли обучение, но не поняли, как новая система помогает им работать быстрее и удобнее, они все равно вернутся к привычным таблицам и ручным схемам. Тогда 1С:ERP остается витриной, а реальная работа продолжается вне нее.
Почему компании затягивают с таким решением
Чаще всего потому, что уже слишком много вложено. Руководству психологически трудно признать, что проект идет не туда. Кажется, что нужно еще немного подождать, добавить еще одну доработку, провести еще одну серию встреч — и все наладится.
Иногда так и бывает. Но, по моему опыту, гораздо чаще новая доработка не решает саму проблему, а просто делает систему еще сложнее.
Я не раз видела проекты, которые внешне выглядели живыми: шли совещания, формировались документы, демонстрировались промежуточные результаты. Но по сути команда уже двигалась не к рабочей системе, а к формальному закрытию этапов. И чем позже руководство это понимает, тем дороже обходится исправление.
Главный вопрос для руководителя
В какой-то момент собственнику или генеральному директору стоит задать себе простой вопрос: может ли проект в его текущем виде привести к работающей системе, которая действительно помогает управлять бизнесом?
Если ответ неочевиден, нужен разбор. Внешний или внутренний — зависит от ситуации. Но без такой паузы компания рискует надолго застрять между формально внедренной 1С:ERP и фактически ручным управлением.
Для меня в этом и состоит смысл разбора проблемного внедрения. Не в поиске виноватых. Не в попытке доказать, кто прав в споре. А в том, чтобы вернуть проект в управляемое состояние и понять, какой путь для бизнеса сейчас действительно разумен: исправлять, пересобирать, менять команду или поставить на паузу до пересмотра всей архитектуры проекта.
ссылка на публикацию companies.rbc.ru
Обсудить
проект
Расскажите о своей проблеме.
Мы предложим лучшее решение и сориентируем по срокам и стоимости.