// notes / crm‑erp
Почему CRM/ERP — это сначала понимание процесса, а потом код
CRM, ERP и личные кабинеты редко ломаются из‑за плохой кнопки. Чаще проблема глубже: никто до конца не разобрался, как в компании движутся заявки, деньги, документы, роли, исключения и ответственность. Если это не понять до разработки, код просто зафиксирует хаос в интерфейсе.
Внутренняя система начинается не с дизайна экранов и не с выбора фреймворка. Сначала нужно понять процесс: кто что делает, в каком порядке, какие данные создаёт, где принимает решение и что происходит, когда сценарий идёт не по плану. Только после этого имеет смысл писать код.
CRM — это не список клиентов
На старте CRM часто описывают очень просто: нужна база клиентов, карточка сделки, задачи, статусы, напоминания, отчёты. Звучит понятно. Почти любой разработчик может быстро нарисовать такую структуру.
Но через пару встреч выясняется, что клиент может быть физлицом и юрлицом, сделка иногда превращается в проект, у проекта есть этапы, документы согласуются разными людьми, часть оплат идёт вручную, менеджеры работают по разным правилам, а отчёт руководителя не совпадает с тем, что вводят исполнители.
Вот здесь и начинается настоящая работа. Не в кнопках. В смысле процесса.
Код быстро делает процесс жёстким
Пока процесс живёт в голове сотрудников, Excel, чатах и устных договорённостях, он гибкий. Не всегда удобный, но гибкий. Люди обходят странные места руками, помнят исключения, договариваются в личке, пересылают файлы, правят статусы задним числом.
Когда мы переносим это в CRM или ERP, система начинает требовать точности. У статуса должен быть список значений. У роли должны быть права. У документа должен быть владелец. У интеграции должен быть источник правды. У отчёта должны быть поля, которые кто‑то реально заполняет.
Если до этого момента процесс не разобран, разработка превращается в бесконечное "а давайте ещё поле", "а у нас бывает иначе", "а можно пока вручную", "а почему отчёт врёт".
Что нужно понять до разработки
Перед кодом я обычно пытаюсь вытащить не список функций, а логику работы. Иногда это неприятно, потому что выясняется: у бизнеса нет единого процесса. Есть набор привычек, исключений и людей, которые держат систему на себе.
Кто участвует
Менеджер, руководитель, бухгалтерия, склад, производство, клиент, подрядчик. У каждого своя зона ответственности и свои права.
Что меняет состояние
Заявка стала сделкой, заказ ушёл в оплату, документ согласован, клиент отказался, товар закончился, срок сорвался.
Где появляются исключения
Нет договора, частичная оплата, ручная скидка, возврат, дубль клиента, два ответственных, нестандартная доставка.
Какие данные важны
Не все поля одинаково нужны. Есть данные для работы, для отчёта, для интеграции, для юридической истории и для контроля качества.
Что должно быть видно
Руководителю нужен контроль, исполнителю — следующий шаг, бухгалтерии — документы, клиенту — понятный статус.
Что нельзя ломать
Права доступа, историю изменений, документы, интеграции, финансовые данные, старые сценарии и отчёты, на которых держится управление.
После такого разбора становится намного проще выбирать архитектуру. Уже видно, где нужна строгая модель данных, где достаточно простого справочника, где важен audit log, а где лучше не усложнять первую версию.
Excel и чаты полезны, но они скрывают проблемы
Я не против Excel. Часто это честный прототип процесса. В таблице видно, какие поля люди действительно используют, какие колонки никто не трогает, где начинаются ручные пометки и костыли.
Проблема начинается, когда таблицу пытаются один в один превратить в систему. Excel спокойно терпит дубли, пустые значения, странные комментарии, смешанные форматы дат и разные правила в соседних строках. CRM так жить не должна. Иначе она станет тем же Excel, только дороже и с логином.
С чатами похожая история. Они хорошо показывают, где процесс ломается. Если сотрудники постоянно уточняют одно и то же в Telegram или WhatsApp, значит в системе не хватает статуса, правила, уведомления, права доступа или нормального источника данных.
Типичные ошибки при разработке CRM/ERP
Плохая внутренняя система редко выглядит плохой в первый день. Интерфейс может быть аккуратным, карточки открываются, кнопки нажимаются. А потом начинаются маленькие трещины.
- начать с экранов, не разобрав статусы и переходы между ними;
- скопировать текущую таблицу Excel и назвать это архитектурой;
- сделать одну роль «администратор», а потом удивляться хаосу в правах;
- не описать исключения, потому что «такое бывает редко»;
- собрать отчёты из данных, которые никто не вводит стабильно;
- добавить интеграцию без понимания, кто отвечает за ошибку обмена.
Почти все эти ошибки появляются не потому, что разработчик не умеет писать код. Чаще он просто начал кодить раньше, чем команда поняла, какую систему на самом деле строит.
Что должно быть до кода
- карта процесса от первого события до закрытия;
- роли и зоны ответственности;
- статусы, переходы и условия переходов;
- документы, файлы, подписи, согласования;
- интеграции и точки отказа;
- права доступа и журнал изменений;
- отчёты, которые бизнес реально будет использовать;
- первый MVP‑контур без попытки автоматизировать всё сразу.
Что можно отложить
- сложные дашборды до стабильных данных;
- полную автоматизацию всех исключений;
- интеграции, которые не нужны в первом рабочем контуре;
- редкие роли и сценарии, если их можно закрыть вручную;
- красивые настройки, пока не ясна базовая логика;
- универсальность «на все случаи жизни».
Как я бы начинал такой проект
Нормальный путь — не пытаться сразу описать идеальную ERP. Лучше собрать первый рабочий контур: процесс, роли, данные, документы, интеграции и отчёты, без которых бизнесу действительно больно.
Разобрать реальный процесс
Не идеальную схему из презентации, а то, как работа происходит сейчас: кто кому пишет, где теряются данные, что обходят руками.
Назвать сущности человеческим языком
Заявка, сделка, заказ, клиент, объект, акт, отгрузка, смена, задача. Если команда не договорилась о словах, код только закрепит путаницу.
Зафиксировать статусы и права
Кто может менять статус, кто видит деньги, кто удаляет документ, кто возвращает задачу назад. В CRM/ERP это не детали, а каркас системы.
Отделить ядро от хотелок
Сначала маршрут, без которого бизнес не работает. Потом удобства, автоматические подсказки, красивые панели и сложная аналитика.
Проверить на исключениях
Хорошая внутренняя система должна переживать не только нормальный сценарий, но и ошибки: возвраты, дубли, задержки, ручные решения, сбои интеграций.
Хорошая CRM/ERP не заставляет бизнес играть в систему
Внутренняя система должна помогать работе, а не создавать отдельную жизнь ради отчётности. Если менеджер вводит данные только потому, что его заставили, эти данные быстро станут мусором. Если руководитель смотрит отчёт, но не доверяет цифрам, отчёт не управляет бизнесом. Если интеграция падает, а никто не отвечает за ошибку, автоматизация превращается в источник ручной работы.
Поэтому в CRM/ERP важны не только таблицы и API. Важны мотивация пользователей, понятные статусы, короткий путь до следующего действия, прозрачные права, история изменений и честный ответ на вопрос: кто принимает решение в спорном случае.
Когда это разобрано, код становится спокойнее. Меньше магии, меньше спорных сущностей, меньше переделок на середине проекта. Система получается не идеальной на бумаге, а рабочей в реальной компании.
CRM/ERP — это не набор экранов, а модель работы бизнеса. Код здесь важен, но он идёт вторым шагом. Сначала нужно понять процесс: роли, статусы, документы, данные, исключения, интеграции и ответственность.
Если этот разбор пропустить, разработка быстро превращается в бесконечную доработку симптомов. Если сделать его нормально, даже первая версия системы может дать порядок: меньше ручной работы, меньше потерь в коммуникации, понятнее контроль и проще развитие.
Если вам нужно спроектировать CRM, ERP, личный кабинет или внутреннюю систему, можно написать мне в Telegram или коротко описать задачу через форму на главной. Начнём не с кнопок, а с процесса.
// related