Семь ошибок при внедрении ERPNext, после которых проект встаёт: разбор от первого лица

Ошибки внедрения ERPNext в малой компании почти всегда одни и те же: доработки раньше процессов, неочищенные справочники, Cost Center на каждый объект, правка ядра, права без User Permission, бэкап без файлов и слабый сервер. Ниже для каждой ошибки симптом, причина и действие.

Почему ERPNext-проекты встают: чаще виноваты процессы, а не программа

За 15 лет работы я видел, как встают проекты на разных системах, и ERPNext тут не исключение. Громкие проценты провалов ERP-проектов, которые гуляют по обзорам, я не цитирую: это общеотраслевые оценки без методики, и к Frappe они относятся не больше, чем к любой другой системе. Важнее другое: в обзорах на малый и средний бизнес причиной провала почти всегда называют не программу, а порядок действий и вовлечённость руководителя. Ниже я разбираю семь ошибок, которые чаще всего вижу в проектах ERPNext под ключ и у тех, кто пытался поставить систему сам. У каждой есть признак, по которому её видно рано, и действие, которое проще сделать сразу, чем исправлять потом.

Сначала карта всех семи ошибок одной таблицей. Дальше разберу каждую подробнее, а эту таблицу можно распечатать и положить рядом с планом внедрения. | № | Симптом | Причина | Действие | |---|---|---|---| | 1 | Теневой Excel, растёт бюджет | Доработки раньше процессов | Описать 5–10 сквозных процессов до настройки | | 2 | Ошибка проведения, нет Cost Center | Cost Center на каждый объект | Project как аналитика объекта | | 3 | Дубли контрагентов | Неочищенные справочники | Импорт по порядку, остатки на дату отсечки | | 4 | Правки пропали после bench update | Правка ядра | Customize Form и fixtures в своём приложении | | 5 | Прораб видит чужие проекты | Роль без User Permission | Ограничение по Link-полю Project | | 6 | После restore нет вложений | Бэкап только базы | Полная копия с файлами и пробное восстановление | | 7 | Request Timed Out | Мало памяти, тяжёлые отчёты | Запас по RAM и нагрузочный тест |

Если вы пока выбираете подрядчика или уже получили брошенный проект, посмотрите ещё материал о том, как восстановить проект после ухода интегратора: многие из семи ошибок там встречаются как следствие, а не как причина. Для внедрения ERPNext это особенно заметно, потому что система гибкая и допускает почти любую настройку, включая неправильную.

Ошибки до запуска: доработки раньше процессов и перенос «хаоса» в справочники

Ошибка первая: доработки раньше процессов. Симптом: система «перегружена», пользователи ведут параллельные таблицы, бюджет растёт без видимых результатов. Причина в том, что заказчик начинает переписывать стандартные документы под старые привычки до того, как описал, как у него устроены закупки, согласование и приём материалов. Мой порядок обратный. Сначала на бумаге описываются пять–десять сквозных процессов (например, «заявка с объекта, согласование, закупка, приёмка, оплата»), потом настраивается коробочная логика, и только после первых недель работы фиксируется список реальных доработок. Обучение идёт по ролям на реальных документах, а не на лекции по меню, и нужен руководитель-спонсор, который арбитрирует споры.

Ошибка вторая: перенос неочищенных справочников. Симптом: дубли контрагентов и номенклатуры, ошибки импорта, неверные остатки. Если вы переносите три таблицы номенклатуры из разных отделов как есть, получаете три версии одного материала. Основное время при переносе уходит на очистку, а не на загрузку, и оценивать его в часах до просмотра исходных таблиц бессмысленно: у компании на девять человек всё зависит от того, в каком состоянии справочники. Я сначала смотрю выгрузку и считаю дубли, а потом называю срок.

Правила переноса у меня простые. Историю документов не переносят: загружают только справочники и остатки на дату отсечки, а старые данные остаются в архиве прежней системы. Загрузка идёт в строгом порядке: сначала пользователи и организации, потом справочники, потом контакты и остатки. Для загрузки есть инструмент Data Import, который сверяет колонки и сообщает об ошибках по строкам. Перед загрузкой справочник чистится в таблице: один материал, одна единица измерения, один контрагент. Это скучная работа, но её нельзя поручить программисту, потому что только вы знаете, какой из двух дублей настоящий.

План счетов и Cost Center: как аналитика на каждый объект ломает отчёты

Ошибка третья: Cost Center на каждый объект. Симптом: ошибки при проведении складских документов, в форме не получается выбрать центр затрат, отчёт о прибылях по организации выглядит как россыпь мелких узлов. Причина в том, что строительные компании привыкли заводить «статью затрат на объект», и в ERPNext это переносят в Cost Center, хотя для коротких проектов есть сущность Project. В исходниках ERPNext версии 15 видно, что Project и Cost Center — стандартные аналитические измерения (Accounting Dimension), и бюджет (Budget) умеет ограничивать по любому из двух: поле Budget Against принимает значения Cost Center и Project.

Мой подход: Cost Center оставляю для подразделений, где затраты нужны надолго (офис, склад, администрация, иногда отдел снабжения), а объект ведётся как Project. Тогда отчёт по объекту собирается по проекту, а центры затрат не раздуваются под каждый короткий заказ. Если нужна дополнительная аналитика (например, «вид работ»), заводится отдельное измерение через Accounting Dimension, и оно появится в документах как поле. В моих проектах бухгалтерский учёт остаётся в 1С, а в ERPNext настраивается упрощённый управленческий план счетов, поэтому сложный бухгалтерский план здесь не нужен.

Отдельная ловушка касается плана счетов. Если вы решили заменить план счетов на свой через импортёр, помните ограничение: в коде версии 15 импортёр останавливается с сообщением, что план счетов можно импортировать только для организации без проводок («Transactions against the Company already exist!»). Поэтому проверять план счетов нужно до первого документа, а не после. Если организация уже работает, исправление превращается в ручную правку счетов и переносы остатков.

Обновления и права: правка ядра, bench migrate и роль без User Permission

Ошибка четвёртая: правка ядра. Симптом: после bench update пропали доработки или система перестала запускаться. Причина — прямое редактирование файлов самого ERPNext или Frappe. Команда bench update при использовании флага --reset по описанию в исходниках bench жёстко сбрасывает git-ветки приложений к новому состоянию и затирает все локальные правки. Правильный путь двухступенчатый: поля и свойства меняются через Customize Form, они сохраняются в базе как записи Custom Field и Property Setter, а для переносимости и версионирования их экспортируют в фикстуры собственного приложения.

Для этого в хуках своего приложения перечисляют, что экспортировать, а затем вызывают команду экспорта:

# hooks.py своего приложения
fixtures = [
    {"dt": "Custom Field", "filters": [["module", "=", "Opalubka Custom"]]},
    {"dt": "Property Setter", "filters": [["module", "=", "Opalubka Custom"]]},
]

bench --site erp.example.com export-fixtures --app opalubka_custom

Экспорт кладёт JSON-файлы в каталог fixtures приложения, а сами файлы фиксируются в Git. Названия приложения и модуля здесь условные. Безопасный маршрут изменения целиком: правка на тестовом стенде, экспорт в фикстуры, коммит, прогон миграции на стенде для проверки сценариев, согласование окна, затем миграция на рабочем сервере. Подробнее про тестовый контур для обновлений — в материале про staging-среду.

Ошибка пятая: роль без User Permission. Симптом: прораб видит чужие проекты или чужие склады. Причина в логике прав Frappe: роль даёт доступ к типу документа, а ограничить записи нужно отдельно. Если пользователю назначена роль с правом читать проекты и при этом нет записи User Permission на конкретный Project, он видит все проекты. User Permission работает только как сужение: без базовой роли доступа не будет вообще, а с ролью и без записи доступ полный. Для прораба я завожу отдельную роль и две записи User Permission: на его проект и на склад его объекта. Если в проекте включается строгий режим, поведение с пустыми значениями меняется, и об этом нужно отдельное тестирование.

Проверка проста и обязательна: войти под тестовым прорабом и пройтись по спискам, отчётам, глобальному поиску и полям выбора. В нашей базе знаний отдельно помечен вопрос, не получает ли прораб доступ к чужим проектам через Kanban Board и отчёты. Я не утверждаю, что обход есть: просто проверяю на каждом проекте, потому что поведение зависит от версии и настроек. Если вы не проверили, считайте доступ открытым.

Инфраструктура: бэкап без файлов, docker compose down -v, тег latest и слабый сервер

Ошибка шестая: бэкап, который не защищает. Симптом: после восстановления документы на месте, а вложений нет. Причина простая: команда bench backup по умолчанию сохраняет только базу, а файлы вложений лежат в каталогах public и private внутри сайта и попадают в копию только с флагом --with-files. Мало того, задание cron, которое создаёт bench setup backups (его же по умолчанию вызывает bench init, если не указан --no-backups), запускает bench --site all backup без этого флага, о чём я подробно пишу в отдельном разборе про бэкапы ERPNext, а проверять копии нужно регулярно, как описано в материале про тест восстановления бэкапа.

В Docker-установках добавляются свои грабли. Команда docker compose down -v по документации Docker удаляет именованные тома вместе с данными, то есть и базу, и файлы сайта. Её привычно набирают, когда нужно «почистить окружение», и на тестовом стенде это нормально, а на рабочем сервере это потеря всего. Вторая грабля — плавающий тег. В официальном compose из репозитория frappe_docker образ собирается из переменной ERPNEXT_VERSION, а в примере окружения она задана конкретной версией, и это правильно: версию нужно фиксировать, а не тянуть latest, иначе перезапуск контейнера может незаметно обновить систему до новой версии вместе с миграциями.

Ошибка седьмая: слабый сервер и отсутствие нагрузочного теста. Симптом: ошибки Request Timed Out, зависающий интерфейс, блокировки в базе. ERPNext запускает несколько фоновых процессов вместе с MariaDB и Redis, а тяжёлые отчёты (остатки по складам за год, журнал проводок) нагружают базу. Из обсуждений на форуме Frappe видно, что массовая параллельная выгрузка документов по REST API приводит к ошибке ожидания блокировки, а создание заказа из заявки на сто с лишним строк в версии 15 у кого-то вызывало задержки интерфейса. Для пяти–десяти пользователей я арендую сервер с запасом по памяти (ориентир 4–8 ГБ, подтвердите нагрузочным тестом на ваших данных) и тестирую тяжёлые отчёты на реальных объёмах до запуска.

Не обещаю, что эти семь ошибок единственные. Они просто самые частые в моей практике, а любая из них, особенно в сочетании, способна остановить проект на этапе, когда пользователи уже заведены, а доверия к системе ещё нет. Поэтому я закрываю их до запуска, а не после первой жалобы.

Как «Опалубка и Ко» избежала повторения этих ошибок на девяти рабочих местах

Условный пример: проектно-строительная фирма «Опалубка и Ко», 9 рабочих мест, три объекта в работе. До внедрения заявки ходили в таблице, согласование шло в переписке, счета лежали в почте, о перерасходе директор узнавал после оплаты. Числа в разборе условные: они показывают ход рассуждений, а не итоги реального клиента, и результат вашего проекта зависит от ваших процессов.

Что сделали по пунктам. Первым шагом на двух совещаниях описали семь сквозных процессов на бумаге и только потом открыли настройки. Три таблицы номенклатуры свели к одному справочнику, перенесли остатки на дату отсечки, историю оставили в архиве. Объекты завели как Project, а Cost Center оставили только для офиса и склада. Доработки не трогали ядро: два дополнительных поля вынесли в собственное приложение с фикстурами в Git, и обновление версии проверяли сначала на тестовом стенде.

Прорабам выдали отдельную роль и записи User Permission на их проект и склад, проверили вход под тестовой учётной записью. Бэкап переделали так, чтобы он включал вложения, добавили копию на второй сервер и ежемесячное пробное восстановление. Сервер взяли с запасом по памяти и перед запуском прогнали самые тяжёлые отчёты. Было и стало в таблице ниже, значения условные. | Было | Стало | |---|---| | Заявки в таблице, согласование в переписке | Заявка с объекта в системе, маршрут согласования | | Три таблицы номенклатуры | Один справочник | | Аналитика объекта в разных файлах | Один Project на объект | | Копия только базы, без проверки | Полная копия и пробное восстановление раз в месяц |

Что проверить на стенде до сдачи проекта: короткий чек-лист

Перед тем как принять систему, я прохожу короткий чек-лист на стенде. Он занимает полдня, а экономит недели. Первое: вход под каждой рабочей ролью, сквозной сценарий от заявки до приёмки без обращения к администратору. Второе: под ролью прораба открыть списки, отчёты, глобальный поиск и поля выбора, убедиться, что чужих проектов и складов нет. Третье: восстановить копию на отдельном стенде и открыть вложение. Четвёртое: убедиться, что доработки лежат в приложении под контролем версий, а не в правках ядра.

Теперь о границах этого списка. Он не заменяет проверку бухгалтерской части: учёт в 1С остаётся отдельной задачей, а обмен данными проверяется своим набором тестов. Он не отвечает на вопрос, нужна ли вам именно ERPNext: для этого есть сравнение с другими системами. Наконец, не все ошибки видны до запуска: некоторые проявляются через месяц, когда накопятся данные, поэтому я назначаю контрольную встречу на конец первого месяца и сверяю статусы документов и отчёты с тем, что ожидал руководитель. Живой пример можно посмотреть на демостенде erp-demo.itfresh.ru по запросу.

Частые вопросы