Как мы внедряли ERP-систему за 5 месяцев — что пошло не так и как выправили
TL;DR: Реализовал цифровизацию учета для промышленного предприятия с устаревшей системой на FoxPro и кучей Excel. За 5 месяцев, 37 встреч с командой и линейными руководителями, 500 часов кода и 4 перезапуска ETL-процессов — запустили кастомную ERP-платформу. До внедрения: 12 часов на формирование отчета, 34% ошибок ввода, дубли в карточках клиентов — до 17 записей на одного. После: отчет за 18 минут, ошибки упали на 89%, время обработки заказа — с 3 дней до 4 часов. 3 критические уязвимости устранены за 7 дней, клиент теперь проходит ежеквартальные пентесты.
Реализовал цифровизацию учета для промышленного предприятия с устаревшей системой на FoxPro, полутора десятками Excel-файлов и ручным вводом на 85% операций. Стандартный аудит инфраструктуры не учитывал специфику производственных процессов, поэтому мы адаптировали подход под реальное состояние — не по мануалу, а по факту.
- Начали с аудита сетевой инфраструктуры: 47 активных хостов, 12 виртуальных машин, 3 физических сервера. Использовали nmap, Nessus и ручной осмотр. На бумаге — все соответствует политике. По факту: обнаружили "забытую" виртуалку с MySQL 5.1, запущенную в 2012 году, на которой работала система контроля доступа. Никто не знал логин и пароль, пришлось восстанавливать через брутфорс хэшей из /etc/shadow. Вытащили данные за два дня, переконвертировали с сохранением внешних ключей. Этот шард чуть не убил всю миграцию — при первом синхронном запуске он вернул битые связи, и база упала. Мало кто проверяет старые сервисы — а 20% сбоев в ERP-проектах связаны именно с таким наследием.
- Выбрали не open-source, а кастомную сборку ERP на базе шестой версии платформы, с доработкой под логистику и цеховые операции. Миграция данных заняла 14 недель вместо запланированных 5. Основная проблема — дубли: в карточках клиентов один юрлицо встречался 17 раз — с разными ИНН, контактами и адресами. Пришлось вручную сопоставлять сделки с 2013 года, чистить и мержить. Ушло 96 часов только на дедупликацию. После — ввели единый реестр контрагентов с валидацией по ОГРН и ИНН через ФНС API
- Интеграция с 1С 8.3 построена на API-шине на RabbitMQ. Первый нагрузочный тест — падение: очередь выросла до 1.2 млн сообщений за 2 часа. Причина — менеджер по запасам запустил скрипт пересчета остатков и забыл завершить. Система начала дублировать операции. Починили через rate limiting (макс. 500 сообщений/мин на очередь) и добавили мониторинг процессов с алертами в Telegram. Теперь любой запуск фоновой задачи требует подтверждения в Jira.
- Пользователи сопротивлялись: требовали старые кнопки, поля и "галочки", даже если те ничего не делали. Решили проблему фейковым интерфейсом: внешний вид — как в FoxPro, но под капотом — REST API и PostgreSQL. Через месяц самi начали просить "сделать по-новому". Обучение строили не на скриншотах, а на копии их рабочих сценариев: как принять заказ, как списать материалы, как сформировать накладную. Ушло 45 часов на адаптацию под 12 ролей
- Финал — аттестация по ИБ. Провели пентест: 14 уязвимостей, из них 3 — критические. Самая опасная — хранение паролей в legacy-модуле по алгоритму MD5 без соли. Закрыли за 7 дней: переписали модуль, ввели двухфакторную аутентификацию и SSO. Клиент теперь проходит аудиты каждые квартал. У нас есть внутренняя методология — гибрид ITIL и Agile: каждый проект получает персональный чек-лист, где учтены особенности инфраструктуры и команды.
Где я налажал: на первом этапе не включил в скрипты проверку целостности данных из 1С. В итоге три дня потрачено на перезапуск ETL. В следующий раз возьму Docker-образ с сервисом валидации и запущу его сразу после подключения.
Что бы сделал иначе: начал бы не с аудита, а с интервью у трех ключевых пользователей. Понял бы их боль раньше и построил миграцию вокруг процессов, а не архитектуры.
Вопрос–ответ
Почему не взяли готовую ERP вроде 1С:ERP или SAP?
Готовые решения не тянули специфику цехового учёта — у них нет привязки к станкам, сменам и ремонтным карточкам. Кастомизация обошлась в 60% от стоимости SAP, но зато работает с 2015 года без переработки.
Как реагировали пользователи после полного перехода?
Через 2 месяца — рост удовлетворенности с 3.1 до 4.6 по 5-балльной шкале. Операторы начали сами предлагать улучшения интерфейса.
Какой стек выбрал и почему RabbitMQ, а не Kafka?
Контур небольшой — до 10к сообщений в минуту. RabbitMQ проще в администрировании и быстрее в развертывании. Kafka — избыточен для такого объема.
Сколько стоила миграция?
Общие затраты — 3.7 млн руб. Из них: 1.2 млн — разработка, 900 тыс. — интеграция, 1.6 млн — консалтинг и обучение.
Комментариев 3