Когда стандартной 1С уже недостаточно: как бизнесу запускать веб-сервисы
на 1С:Элемент

Разберём три принципиальных подхода, которые существуют на рынке, если классическая 1С перестаёт закрывать пользовательский сценарий.

Вариант 1. Дорабатывать классическую 1С

Самый очевидный путь: у компании уже есть 1С, есть команда, которая её знает, есть данные и бизнес-логика. Доработать существующую систему под веб-задачи кажется логичным.

Плюсы:
— существующая экспертиза — не нужно искать новых специалистов;
— данные и бизнес-логика уже в 1С;
— знакомая инфраструктура.

Минусы:
— более длительная разработка;
— необходимы глубокие компетенции в веб-разработке внутри 1С;
— ограничения интерфейса — классическая 1С не предназначена для современных веб-интерфейсов;
— сложности с мобильной адаптацией.

Вариант 2. Отдельная веб-разработка

Второй путь — создать независимый веб-сервис на современном стеке. Например, вариант Next. js + NestJS.

Плюсы:
— максимальная гибкость интерфейса;
— современные технологии и подходы;
— независимость от ограничений 1С.

Минусы:
— нужна отдельная команда веб-разработчиков;
— отдельный frontend и backend — это два технологических контура;
— интеграция с 1С требует дополнительных усилий и постоянной поддержки;
— выше стоимость владения: поддержка нескольких систем, синхронизация данных, обновления.

Вариант 3. 1С: Элемент

Третий путь — использовать платформу 1С: Элемент. Это технология для создания мобильных и веб-приложений в экосистеме 1С. По сути, это low-code платформа, которая во многом повторяет структуру 1С: Предприятие 8: справочники, документы, регистры, встроенный язык на русском.

Ключевое преимущество: 1С: Элемент позволяет использовать существующую 1С-экспертизу для создания веб- и мобильных приложений, не разделяя backend и frontend на разные технологические контуры.

Среди возможностей платформы:

• low-code разработка — в 2−3 раза быстрее классической 1С;
• облачная архитектура или размещение на серверах клиента;
• единый язык, знакомый 1С-разработчикам;
• переиспользуемые компоненты и готовые UI-элементы;
• нативная интеграция с 1С-системами.

При этом, как и у любого инструмента, у 1С: Элемент есть ограничения — например, в части гибкости дизайна и мобильной адаптивности. 

Таким образом, 1С: Элемент — не универсальное решение. Это инструмент, который закрывает конкретный класс задач: когда у компании уже есть 1С, а бизнесу нужен современный веб- или мобильный интерфейс. 

Для DEVCOM нужно было построить партнёрский кабинет, который свяжет партнёров, специалистов и менеджеров в единое информационное поле. И при выборе технологии критичны были три вещи:

• Совместимость с существующим ландшафтом. Компания уже работала в 1С и Битрикс24 — новый сервис должен был встроиться в эту архитектуру, а не заменить её.
• Опора на свою команду. Ключевая экспертиза компании — 1С, а не веб-разработка. Нанимать отдельный штат под один сервис экономически нецелесообразно.
• Скорость запуска. Ручные процессы уже тормозили рост, а партнёрская сеть продолжала расти — ждать год было нельзя.

Технология, которая не закрывала хотя бы одну из этих задач, отпадала — независимо от того, насколько она прогрессивная.

Посмотрим, как это выглядело на конкретном проекте.

DEVCOM — партнёрская сеть Programming Store, которая помогает компаниям находить специалистов с нужными компетенциями и быстро усиливать проектные команды. Сеть запустили во втором квартале 2024 года. К середине 2025 года в ней было более 130 проверенных партнёрских компаний и около 2 000 специалистов.

Партнёрская модель решала три задачи:

• расширение ресурсов — доступ к широкому пулу квалифицированных специалистов;
• гибкость — быстро собрать команду под проект и так же быстро её распустить;
• скорость — предоставлять кандидатов быстрее классического найма.

Механика простая: клиент ставит задачу, DEVCOM находит человека у партнёров, проверяет компетенции, согласует условия и выводит на проект.
Но когда объём операций вырос, ручной контроль начал давать сбои.

Как выглядел процесс до автоматизации:

1. Заявки поступали из Telegram, почты и звонков.
2. В ответ приходили десятки резюме в разных форматах.
3. Менеджеры вручную переносили данные в Bitrix24.
4. Параллельно велись реестры в Google Sheets.
5. Ставки сверялись вручную.
6. Цикл от запроса до первого показа резюме занимал 3−5 дней.

По оценке команды, на механические операции уходило до 60% времени аккаунт-менеджеров. Поиск кандидатов по новой заявке занимал от трёх до пяти дней. Если запрос повторялся, менеджерам приходилось возвращаться к старым перепискам и заново искать подходящих специалистов.

Команде требовалась единая система, в которой партнёры могли бы работать с заявками, а аккаунт-менеджеры — управлять подбором и отслеживать весь процесс.

Что должен был решить новый портал

Команда сформулировала требования к системе. Ключевых блоков было четыре:

Единая точка взаимодействия. Партнёр должен был получить личный кабинет, где видит актуальные запросы, подаёт своих специалистов и отслеживает их статус по каждому запросу. Специалиста можно создать один раз и подавать многократно — без повторного ввода данных.

Автоматизация подбора. Загрузка резюме, AI-парсинг, выделение навыков и опыта, сопоставление специалистов с требованиями запросов, уведомления партнёров. Плюс — кандидатский пайплайн: отслеживание статуса в реальном времени, обратная связь, возможность двигать кандидата по воронке или возвращать на уточнение.

Интеграция. Критичным было не создать ещё одну изолированную систему, а связать её с существующими:

• Битрикс24 — CRM для работы с клиентами;
• 1С:ERP — работа с контрагентами, юридически значимая документация;
• 1С:ДО — внутренний таск-трекер и управление проектами.

Аналитика. Руководству нужны были данные о работе партнёров: эффективность, статусы кандидатов, конверсия, ключевые метрики — в режиме реального времени.

Когда требования были сформированы, команда перешла к выбору технологии. Решение принимали не по принципу «какая технология современнее», а по критериям, важным для бизнеса:

• Как быстро необходимо получить MVP?
• Сколько стоит разработка и поддержка?
• Насколько просто связать с существующей 1С?
• Что произойдёт при росте нагрузки?
• Насколько свободно можно проектировать интерфейс?
• Можно ли подключать внешние AI-сервисы?
• Какие специалисты нужны для развития?

Решение в пользу 1С: Элемент приняли по двум причинам:

1. Нативная интеграция с экосистемой 1С. С Битрикс24, 1С: ERP и 1С: ДО — через встроенные инструменты, без внешних прослоек.
2. Опора на свою команду. Развивать продукт могли существующие 1С-специалисты после дообучения — без найма отдельного штата веб-разработчиков.

Платформа на тот момент была новой, со своими особенностями в дизайне. Команда это понимала и выбрала её осознанно. Логика: скорость запуска и целостность данных важнее гибкости интерфейса.

При этом Битрикс24 не заменяли. Выбрали модульный подход: Битрикс24 остался основной CRM для работы с клиентами, а управление партнёрской сетью и ресурсами вынесли в отдельное приложение на 1С: Элемент, настроив обмен данными между системами.

Как выглядела архитектура решения

Решение построили по модульному принципу. Систему разделили на два взаимосвязанных контура.

Кабинет партнёра — интерфейс, где партнёрская компания:

• видит актуальные запросы и фильтрует их по стеку;
• загружает своих специалистов;
• направляет кандидатов под конкретные запросы;
• отслеживает статус каждого кандидата;
• видит дашборды с показателями своей работы в режиме реального времени.

Рабочее место аккаунт-менеджера — интерфейс со стороны DEVCOM:

• реестр всех партнёров и специалистов;
• синхронизация со сделками из CRM;
• все запросы и поданные кандидаты;
• управление кандидатской воронкой.

Обе стороны работают в едином информационном поле. То, что раньше синхронизировалось через чаты и почту, перешло в систему. 

Ожидаемые результаты

• Цикл подбора сокращается с 3−5 дней до одного рабочего дня. 
• Доля рутинных задач аккаунт-менеджеров снижается на 50−60% — меньше время на переписки в чатах, ручной перенос резюме и сверки ставок.
• Повышение релевантности кандидатов за счёт автоматизированного матчинга.
• Возможность масштабировать партнёрскую сеть и FTE без пропорционального роста команды.
• Повышение прозрачности взаимодействия — все статусы, коммуникация и история работы с кандидатами в одной системе.

Команда регулярно замеряет фактическое время менеджеров на каждом этапе и дорабатывает сценарии, где ещё остаётся ручной труд. Таким образом проект постепенно автоматизируется, сокращая расход ресурсов на рутинные задачи.

1С:Элемент — не универсальный инструмент. У платформы есть особенности, которые важно оценить заранее:

Гибкость дизайна. Дизайн-система платформы менее гибкая, чем у классической веб-разработки. Можно настроить первичный и вторичный цвета, фон, логотип, панель навигации — но это не безграничная кастомизация. В DEVCOM на шлифовку интерфейсов ушло больше времени, чем планировали. В 10-й версии платформы часть доработок уже вошла в типовую функциональность, но ограничения остаются.

Мобильная адаптивность. Есть два варианта клиентского приложения. Стандартное адаптируется автоматически, но даёт меньше свободы в дизайне. Произвольное позволяет настроить свой интерфейс, но требует отдельного приложения под каждое устройство.

Встроенный язык. Он отличается от классического 1С, хотя логика и структура знакомы. 1С-разработчику нужно время на адаптацию — обычно около месяца через курсы.

Команда. Если в штате есть 1С-специалисты — переход пройдёт быстрее. Помогает опыт работы с фронтендом и HTML-контейнерами: они позволяют обходить часть ограничений.

Когда 1С: Элемент может не подойти:

• Если нужен полностью свободный UI/UX.
• Если продукт предполагает нестандартный пользовательский интерфейс.
• Если компания не готова инвестировать в дообучение 1С-команды.
• Если архитектура проекта требует другого технологического стека.

Внедрение 1С: Элемент в DEVCOM не стало финальной точкой. Проект продолжает развиваться, и в дорожной карте — четыре направления.

Публичный фронтенд. Лёгкий внешний интерфейс для частных специалистов — не только для B2B-партнёров. Для них важнее гибкость визуальной части, поэтому здесь потребуется отдельное решение.

Развитие AI. Переход от простых промптов к агентским фреймворкам вроде LangChain и LangGraph. Это нужно, чтобы процесс работы с LLM стал повторяемым и предсказуемым, а не зависел от формулировки запроса.

Сквозная интеграция с учетными системами. Частичная интеграция с 1С: ДО и 1С: ERP уже есть. Дальше — перенос внутренних процессов (отметки времени, календарь занятости специалистов) на платформу с постепенным выводом из 1С: ДО.

Клиентский кабинет. Возможность для заказчиков напрямую отслеживать статус подбора и согласовывать кандидатов — self-service.

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

Прежде чем выбирать технологию для веб-сервиса поверх 1С, стоит ответить на пять вопросов:

1. Какие процессы сегодня тормозят из-за ручных операций?
2. Нужно ли выводить их во внешний веб-интерфейс?
3. Какие данные и процессы должны остаться в существующей 1С?
4. Насколько критична нативная интеграция с 1С?
5. Готова ли текущая 1С-команда развивать новый контур после дообучения?

Ответы на эти вопросы важнее, чем сравнение технологий. Потому что технология — это следствие. Сначала — понимание задачи, потом — выбор инструмента.