Представьте: группа компаний по производству товаров для творчества (пластилин, мозаика, конструкторы), несколько площадок в Иркутске и Подмосковье, 20 лет работы с 1C - и в итоге хаос в учете. Попытки "починить на скорую руку" только усилили проблемы. Разберем, почему так произошло и как этого избежать. Шаг 1. Как накапливался технический долг. Начинали с УТ 10 - классической конфигурации для торговли, затем перешли на УПП без участия аналитика. Настройкой занимались разработчики, а не специалисты по бизнес-процессам. Обмен между УТ 10 и УПП настроили так, что движения начали дублироваться - это создало иллюзию работы системы. Под "хотелки" пользователей ломали стандартный функционал, в итоге конфигурацию сняли с поддержки. Формально все работало, но логика учета размывалась, целостной картины бизнеса не было. Шаг 2. Повтор ошибок при переходе на ERP. Вместо выводов из истории с УПП переход на ERP пошел по тому же сценарию. Сделали ставку на обмены между системами вместо "чистой" логики в одном контуре. Функционал ERP никто глубоко не изучал, разработчики "кодили" без понимания задач бизнеса. Отключили оперативный учет остатков, данные по запасам перестали быть надежными, движения документов стали хаотичными. Поверх нестабильной базы добавили интеграции с "Честным ЗНАКом" и маркетплейсами. Шаг 3. Что именно пошло не так. В какой-то момент ко мне обратились с запросом: "Настройте процессы под одну площадку, а дальше мы сами растиражируем". Я отказалась: уже видела результат такого подхода и не готова была "настроить как-нибудь", а потом отвечать за предсказуемый провал при масштабировании. Если руководство не видит разницы между аналитиком и разработчиком, ответственность за результат логично остается на их стороне. Проблемы проявились на трех уровнях. Технический уровень: обмены превратились в "бомбу замедленного действия", при нескольких площадках синхронизация регулярно дает сбои. Из-за отключения оперативного учета остатки недостоверны, запасы то "исчезают", то "появляются" в базе. Отчеты искажают данные, ERP без оперативного учета становится формальным инструментом. Процессный уровень: нет функционального моделирования, процессы не описаны, backlog задач отсутствует. Разработчики работают "по хотелкам", документация минимальна, система держится на устных договоренностях и знании отдельных людей. Организационный и финансовый уровень: "быстрый пилот" без аудита переносит хаос в новый контур. Масштабирование усиливает ошибки, кризис становится системным. Ошибки в учете грозят штрафами и проблемами с "Честным ЗНАКом". Попытки "подправить" систему стоят все дороже, поддержка нестабильного решения съедает ресурсы, производство страдает от простоев и лишних затрат. Итог - ROI отрицательный, доверие к данным и системе 1C падает. Шаг 4. Как сделать правильно. Устойчивый результат дает только последовательный подход: - Аудит бизнес-процессов: оценить текущее состояние учета, риски и функциональные разрывы. - Функциональное моделирование: описать процессы, сформировать backlog и согласовать целевую модель. - Пилот на одной площадке с обучением: запустить ERP с чистой логикой, минимизировать обмены, собрать обратную связь. - Поэтапное отключение обменов: перевод процессов на единый контур ERP, отказ от "костылей". - Интеграции после стабилизации: подключать "Честный ЗНАК" и маркетплейсы уже к устойчивому учету. Инвестиции в аналитика или методолога: это не лишний расход, а специалист по процессам, который один раз выстраивает рабочую модель ERP вместо многолетнего "ремонта" спонтанных решений. Вывод. Кейс показывает, как экономия на анализе и планировании приводит к многократным потерям. "Быстрые решения" маскируют симптомы, но не устраняют причины. Устойчивый результат дает только связка: сначала аудит и моделирование, затем настройка и обучение, после - масштабирование и интеграции. Отказ участвовать в заведомо провальном сценарии в таких условиях - вопрос профессиональной ответственности, а не жесткости.