Хотел бы рассказать про один проект, где я участвовал сразу в двух ролях: и как разработчик, и как аналитик. Это не история про идеальную архитектуру и не кейс в духе «сделали красиво с первого раза». Скорее наоборот: через боль и страдания, несколько не самых очевидных решений и пара довольно проблемных мест. Но в итоге что-то да получилось.
На старте у нас был бетонный завод с полностью самописной 1С. В ней жила вся управленческая часть, но менеджеров туда лишний раз не пускали. Поэтому начали внедрять Bitrix24, чтобы менеджеры работали в CRM, а всё, что нужно, дальше уже делалось в 1С.
Сначала идея выглядела достаточно прямой. На стороне 1С отдельный разработчик настраивал приём и передачу данных. Я на стороне Bitrix24 поднимал API-часть: получать контрагентов и номенклатуру, передавать обратно заявки и отправлять их в 1С при переходе на нужную стадию. Между менеджером и заводом оставались операторы: они проверяли заявку, и только потом она уходила в производство.
Что быстро стало проблемой
Самая неприятная история началась с товарной части. В 1С это был не один общий блок, а три отдельные табличные части:
-
для клиента;
-
для завода;
-
для дилера.
Часть позиций между ними совпадала, но часть отличалась. Где-то нужна была доставка, где-то нет. Где-то были сопутствующие позиции, где-то другая логика комплектации. То есть по сути каталог один, а фактически сценариев несколько.
И вот тут Bitrix24 начал упираться в свои ограничения. В каталоге было порядка 2000 номенклатурных позиций, но в сделке это нужно было показывать как три разных товарных зоны. Типовыми средствами сделать это нормально не получилось.
Так как у нас была коробочная версия, пошли в доработку. Добавили свой тип поля, который умел обращаться напрямую к товарному каталогу и давал нормальный поиск. Это было важно не ради «кастома ради кастома», а чисто из практики: менеджеру нужно быстро найти нужную позицию, а не открывать огромный список и листать его вручную.
В результате заявка собиралась в Bitrix24, менеджер заполнял объект, позиции и прочие данные, а дальше в 1С улетал большой JSON обычным POST-запросом, где на стороне 1С уже создавался документ.
Тут вроде бы казалось что все работает хорошо и этого достаточно.
Почему только такого варианта оказалось недостаточно
Со временем стало понятно, что технически процесс есть, а по факту люди всё равно работают по-старому.
Менеджеры заполняли заявку в Bitrix24, а потом ещё писали в чаты и мессенджеры на завод, чтобы там точно увидели заказ и подтвердили, что его можно принять. Получалась классическая двойная работа: один и тот же заказ жил и в CRM, и в переписке.
В офисе это ещё справлялись только с работой в Битриксе. Но была вторая группа пользователей: дилеры и менеджеры, которые работают «в полях» и могут оформлять заказ прямо с объекта. И вот для них мобильный сценарий оказался неудобным.
Сама мобильная версия Bitrix24 в целом была нормальной, но наш кастомный тип поля там просто не отображался. Мы несколько раз пытались решить это через поддержку Bitrix24, но внятного решения так и не получили.
Именно в этот момент стало ясно, что проблема уже не в интеграции как таковой. Проблема была в том, что офисный сценарий ещё можно натянуть на CRM, а полевой сценарий — уже нет.
Какие варианты мы вообще рассматривали
Первый вариант был самый очевидный: купить планшеты и раздать менеджерам.
Но это решало вопрос только для своих сотрудников. С дилерами такой подход не работал вообще. Это отдельные компании со своей инфраструктурой, и заставить их пользоваться «нашим» устройством или «нашим» процессом было бы очень сложно.
Второй вариант был уже более жизненный: сделать отдельное небольшое приложение, которое работает вокруг Bitrix24, но не заставляет дилеров заходить в сам Bitrix24. То есть дать им простой интерфейс для создания и отслеживания заявок, а внутри уже синхронизировать всё с CRM и 1С.
В итоге пошли именно в эту сторону.
Как собирали приложение
Тут надо честно сказать: бюджет у этой идеи был не очень большой. Поэтому часть решений принималась не из позиции «как сделать идеально», а из позиции «как быстро проверить гипотезу и не утонуть по дороге». Для самого первого прототипа я даже использовал Claude Code, чтобы быстро набросать каркас и вообще понять, взлетит ли такой сценарий.
Требования к приложению были достаточно простые:
-
нормально работать на телефоне;
-
давать быстрый выбор контрагентов и номенклатуры (При чем только контрагентов за которым этот менеджер или дилер был ответственный);
-
показывать статус заявки;
-
убирать постоянную необходимость писать оператору в чат.
По стеку взяли довольно простой набор: FastAPI, Vue и Postgres.
В первой итерации я пошёл самым прямым путём. Сделал форму, по сути синхронизированную со сделкой в Bitrix24. Все поля сначала были прописаны вручную. Потом стало понятно, что так долго не прожить, и я сделал редактор форм, где можно было подтягивать поле напрямую из Bitrix24 и сопоставлять его с полем в приложении, все по RestApi.
Поиск компаний и номенклатуры сначала тоже работал напрямую через API Bitrix24. Для прототипа этого хватало: найти нужного контрагента, подобрать позиции, отправить форму, получить сделку в CRM.
Но на реальной задаче этот подход быстро начал тормозить весь сценарий.
Почему поиск пришлось выносить в локальный контур
Напрямую жить на API Bitrix24 оказалось тяжело. Где-то ответы приходили медленно, где-то поиск вёл себя нестабильно, где-то вся форма становилась слишком зависимой от внешнего сервиса.
В какой-то момент я подумал и решил, что дёргать CRM при каждом пользовательском действии — плохая идея. Подключил Elasticsearch, настроил регламентное обновление данных примерно раз в 20-30 минут и начал строить индексы уже у себя.
Если смотреть назад, я не уверен, что сегодня снова выбрал бы именно Elasticsearch. Возможно, для такой задачи я бы скорее смотрел в сторону Meilisearch. Но на тот момент решение сработало: поиск стал локальным, форма начала работать заметно быстрее, а сам пользовательский сценарий перестал зависеть от каждого чиха со стороны Bitrix24.
По тому же принципу потом подтянули и историю заявок, и данные для карточек: нужную информацию по клиенту и позициям стало проще отдавать из своих индексов, чем каждый раз собирать её на лету.
Самая неприятная проблема оказалась не в API, а в Android
Вот тут я понял что затея может не увенчаться успехом.
Разрабатывал и тестировал я в основном на яблокофоне. На нем всё выглядело более-менее прилично. А потом выяснилось, что на обычных Android-смартфонах, особенно на бюджетных, интерфейс начинает сильно тормозить. Причём проблема была не в сети и не в API, а именно в рендере страниц.
В некоторых местах форма висла так, что ей просто невозможно было пользоваться. Это уже был критичный момент, потому что если приложение нормально не работает на Android, значит для большей части пользователей весь проект просто теряет смысл.
В итоге проблема оказалась довольно приземлённой: инпуты и их рендер. После этого фронт пришлось почти полностью переписать. Зато после переработки приложение стало нормально жить даже на обычных недорогих смартфонах.
Для меня это был отдельный вывод: мобильный сценарий нельзя считать закрытым, пока ты не прогнал его не только на своём устройстве.
Что в итоге получилось по процессу
В финале у нас сложилось три отдельных контура, которые между собой синхронизируются:
-
1С;
-
Bitrix24;
-
отдельное приложение для оформления и отслеживания заявок.
Между ними остался промежуточный слой операторов, которые валидируют изменения, но и он сильно сократился. Раньше на этом сидело шесть человек. После запуска новой схемы осталось два. Остальных уже можно было переводить на более полезные задачи, а не держать в вечных чатах и ручных сверках.
Пара вещей сработала особенно хорошо.
Во-первых, редактор форм с привязкой к полям Bitrix24. Когда администратор создаёт поле, ему не нужно лезть в код. Он указывает ID поля Bitrix24, а система подтягивает его имя и, если это список, ещё и значения. В итоге многие изменения дальше уже мог делать не разработчик, а специалист со стороны клиента.
Во-вторых, хорошо показала себя логика обработки изменений в заявке. Когда заявка создаётся в приложении, в Bitrix24 появляется сделка на стадии квалификации. Оператор получает задачу с перечнем того, что было заказано, проверяет её и, если всё нормально, закрывает задачу. После этого сделка уходит на стадию «отправлено в производство», а дальше данные уходят в 1С.
Если в заявке потом что-то меняется, система снова возвращает её на квалификацию и ставит оператору новую задачу. Причём не просто «проверьте ещё раз», а с комментарием, где видно, что именно изменилось. За счёт этого оператору не нужно перечитывать всю заявку заново и гадать что же было изменено.
При этом после того, как в 1С начинается отгрузка, дальнейшие изменения уже не должны влиять на производство. Эту границу мы тоже отдельно учитывали: после определённого статуса данные в 1С больше не перетираются. Зато обратная информация о статусе всё равно уходит назад в Bitrix24 и в приложение, чтобы менеджер и дилер видели, что происходит с заказом.
И одна из самых полезных вещей в этом проекте — заявки на период. Если клиенту нужно, например, возить бетон по графику целый месяц, менеджеру не надо руками делать десяток однинаковых заявок. Он заполняет одну форму, указывает период, даты, время, объёмы, а система сама создаёт нужное количество заявок по расписанию.
Для бизнеса это оказалось реально маст хэф, потому что такие истории бывают часто и дают основной объём.
Что бы я сейчас сделал иначе
Если смотреть на проект сейчас, я бы точно меньше радовался мысли «сейчас быстро всё допишем сами».
Я бы внимательнее посмотрел в сторону готовых админ-решений, которые можно адаптировать под задачу, а не строить весь контур полностью с нуля. Не факт, что это подошло бы идеально, но часть самописной инфраструктуры точно можно было бы не тащить на себе.
По поиску я бы ещё раз подумал над выбором инструмента. Тогда Elasticsearch задачу закрыл, но сейчас я бы, скорее всего, смотрел и на более лёгкие варианты.
Ещё один важный момент — отложенная отправка. Сейчас, если Bitrix24 недоступен, приложение может сохранить данные у себя, но полноценной очереди на повторную отправку у нас не было. А такую механику стоило делать сразу, потому что она сильно снижает зависимость всей схемы от внешнего сервиса.
Ну и тестирование на Android я бы вынес в обязательный сценарий с самого начала, а не оставлял это на этап «вроде уже почти всё готово».
Что для меня в этом кейсе главное
Этот проект мне нравится не потому, что там был какой-то особенно красивый стек. Скорее наоборот: многие решения были очень прагматичными, а местами и откровенно внезапыными.
Но в итоге я c коллегами решил реальную проблему бизнеса.
Убрали двойную работу.
Ушли от чатов как от основного канала согласования.
Дали дилерам и менеджерам удобный мобильный сценарий.
Сократили ручную валидацию с шести человек до двух.
И, наверное, это для меня главный критерий удачного проекта. Не то, насколько он красиво звучит на архитектурной схеме, а то, начали ли им в итоге нормально пользоваться люди.
ссылка на оригинал статьи https://habr.com/ru/articles/1025276/