Low-code и no-code: в чём разница и когда что применять
Определения занимают две главы, дальше — точки отказа на реальных задачах, цена изменений и вопросы, которые решают выбор платформы.
Коротко
Коротко
- Разница между low-code и no-code не в объёме кода, а в том, где вы упрётесь в потолок платформы.
- No-code упирается на четырёх типовых задачах — ролевой модели, своём расчёте, обмене по нестандартному протоколу и выгрузке в чужой формат.
- «Бизнес-пользователь меняет сам» верно на уровне полей и текстов. Логика и права почти всегда требуют человека, который знает платформу.
- С 2025 года важнее не деление по объёму кода, а другое — собираете вы приложение руками или платформа собирает его по описанию.
- Vendor lock-in измеряется одним вопросом: в каком виде вы получите приложение, если решите уйти.
Коротко: в чём разница
No-code и low-code — два способа собрать приложение, не программируя его целиком. В no-code программировать нельзя вовсе, всё собирается визуально. В low-code основную часть тоже собирают визуально, но для нетиповых мест остаётся возможность дописать логику кодом.
Определение через объём кода даёт правильный ответ на экзамене и почти ничего не говорит о выборе. Практически разница в другом. Она в том, где вы упрётесь в потолок и что сможете сделать, когда упрётесь.
Путаница в терминах возникла не случайно. Слово no-code продаёт лучше, потому что обещает обойтись без ИТ-отдела, и его ставят на страницы платформ, где код давно предусмотрен. Обратное тоже встречается — платформа называет себя low-code, чтобы выглядеть серьёзнее в глазах ИТ-директора, хотя дописать в неё ничего нельзя. Поэтому определять класс по формулировке на сайте бессмысленно; надёжнее задать один вопрос — что делать, когда готового блока для задачи не окажется.
Аналогия с конструктором, которую повторяет половина обзоров, тут скорее мешает. Из деталей конструктора действительно нельзя сделать деталь другой формы, но корпоративная задача обычно проваливается не на форме элемента, а на связях между ними.
Определение через объём кода даёт правильный ответ на экзамене и почти ничего не говорит о выборе. Практически разница в другом. Она в том, где вы упрётесь в потолок и что сможете сделать, когда упрётесь.
Критерий | No-code | Low-code |
Кто собирает | Сотрудник с пониманием процесса | Тот же сотрудник, а на сложных местах — разработчик |
Скорость первого результата | Часы и дни | Дни и недели |
Что происходит на нетиповой задаче | Обходной путь или отказ | Дописывается кодом |
Потолок | Набор готовых блоков платформы | Готовые блоки плюс своя логика |
Порог входа | Низкий | Средний, нужна квалификация на платформе |
Типичное применение | Формы, простые заявки, сайты, кабинеты с базовой логикой | Внутренние системы с ролями, маршрутами и интеграциями |
Путаница в терминах возникла не случайно. Слово no-code продаёт лучше, потому что обещает обойтись без ИТ-отдела, и его ставят на страницы платформ, где код давно предусмотрен. Обратное тоже встречается — платформа называет себя low-code, чтобы выглядеть серьёзнее в глазах ИТ-директора, хотя дописать в неё ничего нельзя. Поэтому определять класс по формулировке на сайте бессмысленно; надёжнее задать один вопрос — что делать, когда готового блока для задачи не окажется.
Аналогия с конструктором, которую повторяет половина обзоров, тут скорее мешает. Из деталей конструктора действительно нельзя сделать деталь другой формы, но корпоративная задача обычно проваливается не на форме элемента, а на связях между ними.
No-code: что это и что реально собирают
No-code платформа даёт визуальный редактор и набор готовых элементов. Вы перетаскиваете поля, настраиваете зависимости, описываете переходы между шагами — и получаете работающее приложение, ни разу не открыв редактор кода.
Что на no-code собирают хорошо и часто.
Ключевое свойство класса — предсказуемость. Всё, что собрано из готовых блоков, ведёт себя одинаково, обновляется вместе с платформой и не требует поддержки в обычном смысле слова. Это же свойство оборачивается ограничением, как только задача выходит за набор блоков.
Быстрее всего границы видно на MVP: за неделю собирается форма, один маршрут и статусы — что входит в такой MVP, а что остаётся на потом.
Что на no-code собирают хорошо и часто.
- Формы сбора данных с проверками и уведомлениями.
- Простые заявочные сервисы, где маршрут прямой и согласующий один.
- Реестры и справочники с фильтрами и выгрузкой.
- Внутренние сайты и порталы с новостями и документами.
- Кабинеты, где пользователь смотрит свои данные и оставляет обращения.
Ключевое свойство класса — предсказуемость. Всё, что собрано из готовых блоков, ведёт себя одинаково, обновляется вместе с платформой и не требует поддержки в обычном смысле слова. Это же свойство оборачивается ограничением, как только задача выходит за набор блоков.
Быстрее всего границы видно на MVP: за неделю собирается форма, один маршрут и статусы — что входит в такой MVP, а что остаётся на потом.
Low-code: что добавляет возможность писать код
Low-code устроен так же, но оставляет двери. Там, где визуального блока не хватает, можно вставить свою функцию, свой запрос к данным или свой обработчик события. Основная часть приложения при этом остаётся собранной визуально.
Практический смысл этих дверей виден на трёх типах задач. Свой расчёт, который не выражается формулой из готового набора. Обмен с внешней системой, у которой нестандартный протокол или собственный формат. Нетиповая проверка данных, зависящая от нескольких сущностей одновременно.
Цена дверей тоже понятная. Как только в приложении появился свой код, у него появился и владелец этого кода. Обновление платформы теперь может задеть вашу вставку, и кто-то должен это проверять. Поэтому разумная практика — держать долю своего кода минимальной и осознанной, вместо того чтобы расширять её при каждом неудобстве.
Практический смысл этих дверей виден на трёх типах задач. Свой расчёт, который не выражается формулой из готового набора. Обмен с внешней системой, у которой нестандартный протокол или собственный формат. Нетиповая проверка данных, зависящая от нескольких сущностей одновременно.
Цена дверей тоже понятная. Как только в приложении появился свой код, у него появился и владелец этого кода. Обновление платформы теперь может задеть вашу вставку, и кто-то должен это проверять. Поэтому разумная практика — держать долю своего кода минимальной и осознанной, вместо того чтобы расширять её при каждом неудобстве.
Zero-code, RPA, BPM: как в этом не запутаться
Рядом с двумя основными терминами живут ещё три, и путаница между ними стоит компаниям неверных решений.
Zero-code — маркетинговый синоним no-code. Разницы в существе нет, слово используют, чтобы подчеркнуть полное отсутствие программирования.
RPA решает другую задачу. Робот не собирает приложение, а повторяет действия человека в уже существующей программе — открывает окна, копирует значения, нажимает кнопки. RPA берут там, где у системы нет API и получить его невозможно. Российский рынок здесь поделён между ROBIN, Primo RPA, PIX Robotics и Sherpa RPA.
BPM — это про процессы, и способ сборки к нему отношения не имеет. BPM-система моделирует и исполняет маршруты работ, и делать это она может как визуально, так и кодом. Большинство современных BPM-платформ одновременно являются low-code платформами, отсюда и смешение понятий.
Практический вывод. Если вам нужно приложение — смотрите на no-code и low-code. Если нужно навести порядок в сквозном процессе — на BPM. Если нужно закрыть участок, где к системе не подступиться, — на RPA.
Zero-code — маркетинговый синоним no-code. Разницы в существе нет, слово используют, чтобы подчеркнуть полное отсутствие программирования.
RPA решает другую задачу. Робот не собирает приложение, а повторяет действия человека в уже существующей программе — открывает окна, копирует значения, нажимает кнопки. RPA берут там, где у системы нет API и получить его невозможно. Российский рынок здесь поделён между ROBIN, Primo RPA, PIX Robotics и Sherpa RPA.
BPM — это про процессы, и способ сборки к нему отношения не имеет. BPM-система моделирует и исполняет маршруты работ, и делать это она может как визуально, так и кодом. Большинство современных BPM-платформ одновременно являются low-code платформами, отсюда и смешение понятий.
Практический вывод. Если вам нужно приложение — смотрите на no-code и low-code. Если нужно навести порядок в сквозном процессе — на BPM. Если нужно закрыть участок, где к системе не подступиться, — на RPA.
ЕСТЬ ЕЩЁ ОДНО ДЕЛЕНИЕ
Собирать самому или описать задачу словами
Nolan — ИИ-ассистент, который собирает приложение на low-code платформе. Он не заменяет платформу, а работает поверх неё.
Разница с обычной работой на платформе в том, кто выполняет сборку. Вы описываете задачу словами или загружаете ЧТЗ, ассистент переводит описание на объектный язык платформы — сущности, поля, роли, экраны, маршруты — и собирает приложение из её компонентов. Дальше правки вносятся в чате.
С заказной разработкой это сравнивается по устройству цикла. Там между потребностью и работающей системой стоит очередь и релиз на каждое изменение. Здесь очереди нет.
Собирать самому или описать задачу словами
Nolan — ИИ-ассистент, который собирает приложение на low-code платформе. Он не заменяет платформу, а работает поверх неё.
Разница с обычной работой на платформе в том, кто выполняет сборку. Вы описываете задачу словами или загружаете ЧТЗ, ассистент переводит описание на объектный язык платформы — сущности, поля, роли, экраны, маршруты — и собирает приложение из её компонентов. Дальше правки вносятся в чате.
С заказной разработкой это сравнивается по устройству цикла. Там между потребностью и работающей системой стоит очередь и релиз на каждое изменение. Здесь очереди нет.
- не нужен специалист, который знает платформу
- правки в чате без нового релиза
- заявленный эффект — в 10–50 раз меньше трудозатрат на типовое решение
Где заканчивается no-code: четыре точки отказа
Обзоры пишут «когда нужна гибкость» и на этом останавливаются. На практике отказ происходит в четырёх узнаваемых местах, и все четыре можно проверить до выбора платформы.
Ролевая модель сложнее плоской. Готовые платформы уверенно делают роли уровня «администратор, менеджер, наблюдатель». Задача ломается, когда доступ зависит от данных — руководитель филиала видит только свой филиал, менеджер видит только своих клиентов, а закупщик видит все заявки, но суммы только до своего порога. Проверяется просьбой показать такой доступ на демо.
Расчёт по своей формуле. Скидка, которая зависит от объёма, истории заказов и категории клиента одновременно. Норматив, который считается по внутреннему регламенту. Готовый набор функций такое обычно не покрывает, и появляется либо обходной путь через дополнительные поля, либо код.
Обмен по нестандартному протоколу. У большинства платформ есть готовые коннекторы к популярным системам и универсальный способ работы с API. Задача ломается, когда на другой стороне нет API вовсе или обмен идёт файлами по своему формату — тогда нужен разбор формата, а это уже логика.
Выгрузка в чужой шаблон. Печатная форма по требованиям контрагента, отчёт в формате регулятора, файл для загрузки в стороннюю систему. Собрать структуру данных легко, попасть в точный формат — почти всегда работа за пределами готовых блоков.
Если хотя бы две точки из четырёх встречаются в вашей задаче, no-code не подойдёт, и выбирать надо между low-code и разработкой.
Ролевая модель сложнее плоской. Готовые платформы уверенно делают роли уровня «администратор, менеджер, наблюдатель». Задача ломается, когда доступ зависит от данных — руководитель филиала видит только свой филиал, менеджер видит только своих клиентов, а закупщик видит все заявки, но суммы только до своего порога. Проверяется просьбой показать такой доступ на демо.
Расчёт по своей формуле. Скидка, которая зависит от объёма, истории заказов и категории клиента одновременно. Норматив, который считается по внутреннему регламенту. Готовый набор функций такое обычно не покрывает, и появляется либо обходной путь через дополнительные поля, либо код.
Обмен по нестандартному протоколу. У большинства платформ есть готовые коннекторы к популярным системам и универсальный способ работы с API. Задача ломается, когда на другой стороне нет API вовсе или обмен идёт файлами по своему формату — тогда нужен разбор формата, а это уже логика.
Выгрузка в чужой шаблон. Печатная форма по требованиям контрагента, отчёт в формате регулятора, файл для загрузки в стороннюю систему. Собрать структуру данных легко, попасть в точный формат — почти всегда работа за пределами готовых блоков.
Если хотя бы две точки из четырёх встречаются в вашей задаче, no-code не подойдёт, и выбирать надо между low-code и разработкой.
Кто вносит правки и какой ценой
«Бизнес-пользователь меняет сам» — самая частая фраза в описаниях платформ и самая неаккуратная. Она верна не для всех изменений, и разница между уровнями изменений огромная.
Из этой таблицы следует практический вопрос к вендору. Не «может ли бизнес-пользователь менять», а «кто в нашей компании будет делать изменения третьего и четвёртого уровня». Если ответа нет, приложение начнёт стареть с первого месяца — не потому, что платформа плохая, а потому что менять его некому.
Второй вопрос про обучение. Платформа требует квалификации, и эту квалификацию кто-то должен получить. Практика показывает, что один обученный сотрудник — это риск, потому что вместе с его уходом компания теряет возможность менять свои системы.
Отсюда практика, которая себя оправдывает в компаниях от сотни человек. Квалификацию по платформе держат не в одном человеке, а в двух-трёх, и обязательно с разными подразделениями за спиной. Тогда изменения не встают в очередь к единственному специалисту, а знание платформы не уходит вместе с сотрудником. Стоит это дороже одного обученного человека и заметно дешевле повторного внедрения через год.
Что меняем | Кто реально может | Сколько занимает |
Текст, подсказку, название поля | Любой сотрудник с доступом | Минуты |
Добавить поле в форму, поменять фильтр | Сотрудник, прошедший обучение платформе | Десятки минут |
Добавить шаг согласования или роль | Специалист, знающий платформу | Часы, иногда дни |
Поменять логику расчёта или интеграцию | Разработчик или внедренец | Дни, через постановку задачи |
Из этой таблицы следует практический вопрос к вендору. Не «может ли бизнес-пользователь менять», а «кто в нашей компании будет делать изменения третьего и четвёртого уровня». Если ответа нет, приложение начнёт стареть с первого месяца — не потому, что платформа плохая, а потому что менять его некому.
Второй вопрос про обучение. Платформа требует квалификации, и эту квалификацию кто-то должен получить. Практика показывает, что один обученный сотрудник — это риск, потому что вместе с его уходом компания теряет возможность менять свои системы.
Отсюда практика, которая себя оправдывает в компаниях от сотни человек. Квалификацию по платформе держат не в одном человеке, а в двух-трёх, и обязательно с разными подразделениями за спиной. Тогда изменения не встают в очередь к единственному специалисту, а знание платформы не уходит вместе с сотрудником. Стоит это дороже одного обученного человека и заметно дешевле повторного внедрения через год.
Третье деление: кто выполняет сборку
Деление по объёму кода придумано до 2023 года, и оно перестало объяснять картину. Появился второй разрез, который для выбора важнее.
С одной стороны — инструменты для ручной сборки. Платформа даёт редактор, человек собирает приложение сам. Сюда попадают и no-code, и low-code платформы, различаясь только тем, можно ли дописать код.
С другой — сборка по описанию. Человек описывает задачу словами, а приложение собирает ассистент, переводя описание в формальную модель платформы. Возможности при этом остаются теми же, потому что и в том и в другом случае потолок задаёт платформа. Меняется только то, нужен ли вам специалист по этой платформе.
Почему это важнее старого деления. Компания выбирает платформу один раз, а сталкивается с вопросом «кто это сделает» каждый раз. Если специалиста нет и не появится, разница между no-code и low-code становится второстепенной — обе платформы будут простаивать.
С одной стороны — инструменты для ручной сборки. Платформа даёт редактор, человек собирает приложение сам. Сюда попадают и no-code, и low-code платформы, различаясь только тем, можно ли дописать код.
С другой — сборка по описанию. Человек описывает задачу словами, а приложение собирает ассистент, переводя описание в формальную модель платформы. Возможности при этом остаются теми же, потому что и в том и в другом случае потолок задаёт платформа. Меняется только то, нужен ли вам специалист по этой платформе.
Почему это важнее старого деления. Компания выбирает платформу один раз, а сталкивается с вопросом «кто это сделает» каждый раз. Если специалиста нет и не появится, разница между no-code и low-code становится второстепенной — обе платформы будут простаивать.
Когда что применять
Сводка по типам задач. Столбец «чем закрывать» стоит читать как отправную точку — многое зависит от конкретной платформы.
Отдельно про сочетания. В жизни компания редко выбирает один способ. Учёт остаётся в готовой системе, внутренние сервисы уезжают на платформу, участок без API закрывает робот. Такая раскладка выглядит менее красиво, чем единая платформа, и работает лучше.
Выбор инструмента — второй шаг. Первый — понять, какой процесс вообще стоит автоматизировать: как выбрать первый процесс и чем его закрыть.
Задача | Чем закрывать | Почему |
Форма заявки с уведомлениями | No-code | Всё есть в готовых блоках |
Реестр договоров с фильтрами и выгрузкой | No-code | Структура данных и представления — типовая работа |
Кабинет клиента с просмотром заказов | No-code, если данные приходят готовыми | Логики мало, основное — представление |
Согласование с порогами сумм и ветвлением | Low-code | Ветвление по данным выходит за плоские правила |
Заявки в службы со сроками и приоритетами | Low-code | Расчёт срока и эскалация требуют логики |
Портал сотрудника с доступом по подразделениям | Low-code | Ролевая модель зависит от данных |
Обмен с 1С по своему формату | Low-code | Разбор формата — это код |
Публичный высоконагруженный сервис | Разработка | Требования к отклику и архитектуре |
Продукт со своим уникальным алгоритмом | Разработка | Алгоритм и есть ценность продукта |
Отдельно про сочетания. В жизни компания редко выбирает один способ. Учёт остаётся в готовой системе, внутренние сервисы уезжают на платформу, участок без API закрывает робот. Такая раскладка выглядит менее красиво, чем единая платформа, и работает лучше.
Выбор инструмента — второй шаг. Первый — понять, какой процесс вообще стоит автоматизировать: как выбрать первый процесс и чем его закрыть.
ЧТО ОСТАЁТСЯ У ВАС
Приложение не заперто в конструкторе
По собранному приложению формируется итоговое ТЗ и документация на его функциональность — сущности, поля, роли, экраны, маршруты. Описание версионируется, и разработку по нему продолжают дальше, поэтому цикл сборки не односторонний. Это ответ на главный страх при выборе любой платформы, и его стоит проверять у каждого вендора, а не только у нас.
Второе, что имеет значение при разговоре о зависимости, — модели. Интеллектуальный слой работает на GigaChat, YandexGPT и собственных дообученных локальных моделях, размещение в России, а единый протокол позволяет переключаться между моделями без перестройки приложений. Появится более сильная отечественная модель — конвейер переедет на неё, приложения переделывать не придётся.
Приложение не заперто в конструкторе
По собранному приложению формируется итоговое ТЗ и документация на его функциональность — сущности, поля, роли, экраны, маршруты. Описание версионируется, и разработку по нему продолжают дальше, поэтому цикл сборки не односторонний. Это ответ на главный страх при выборе любой платформы, и его стоит проверять у каждого вендора, а не только у нас.
Второе, что имеет значение при разговоре о зависимости, — модели. Интеллектуальный слой работает на GigaChat, YandexGPT и собственных дообученных локальных моделях, размещение в России, а единый протокол позволяет переключаться между моделями без перестройки приложений. Появится более сильная отечественная модель — конвейер переедет на неё, приложения переделывать не придётся.
- итоговое ТЗ и документация на собранное приложение
- независимость от конкретной языковой модели
Vendor lock-in: как проверить у вендора
Зависимость от платформы обсуждают редко и обычно одной фразой про то, что работоспособность зависит от провайдера. Вопрос стоит разобрать до подписания, потому что стоимость выхода определяется в момент входа.
Пять вопросов, которые дают полную картину.
Ни один из пяти ответов сам по себе не дисквалифицирует платформу. Отказ отвечать — дисквалифицирует.
Пять вопросов, которые дают полную картину.
- В каком виде я получу приложение, если решу уйти? Экспорт конфигурации, выгрузка данных, документация на функциональность, исходный код — ответы разные, и последствия у них тоже разные.
- Данные я получу в структуре платформы или в своей? Выгрузка, которую невозможно загрузить в другую систему без переделки, формально экспорт, практически нет.
- Что произойдёт с приложением, если платформа перестанет развиваться? Ответ «оно продолжит работать» имеет смысл только при размещении в вашем контуре.
- Кто, кроме вендора, умеет работать с этой платформой? Наличие рынка внедренцев — страховка от зависимости от одной команды.
- Как устроено лицензирование при росте? Плата за пользователя на горизонте трёх лет меняет экономику решения сильнее, чем стоимость внедрения.
Ни один из пяти ответов сам по себе не дисквалифицирует платформу. Отказ отвечать — дисквалифицирует.
Что просить показать на демо
Демонстрация по сценарию вендора почти ничего не сообщает — она собрана из задач, которые платформа делает хорошо. Полезнее прийти со своим списком и попросить показать пять вещей.
Если на любой из пяти пунктов отвечают «это делается на этапе внедрения» — вопрос не закрыт, а перенесён на время, когда договор уже подписан.
- Наш процесс с ветвлением. Не абстрактную заявку, а свой маршрут с порогами и несколькими согласующими. Смотрите, сколько шагов настройки на это ушло.
- Доступ под другой ролью. Попросите зайти как руководитель филиала и убедитесь, что чужие данные действительно не видны, а не просто скрыты в интерфейсе.
- Наши данные. Загрузите свой справочник контрагентов с дублями и опечатками. На демонстрационных записях работает любая платформа.
- Изменение на ходу. Попросите прямо во время демо добавить поле и шаг согласования. Это единственный способ увидеть реальную цену будущих правок.
- Обмен с вашей учётной системой. Хотя бы на уровне разговора о том, как именно данные попадут внутрь и что произойдёт, когда обмен недоступен.
Если на любой из пяти пунктов отвечают «это делается на этапе внедрения» — вопрос не закрыт, а перенесён на время, когда договор уже подписан.
Что нельзя закрыть ни low-code, ни no-code
Класс задач, где выбор между платформами не имеет значения, потому что подходит только разработка.
Признак, по которому такую задачу видно заранее, простой. Если в требованиях есть число — столько-то запросов в секунду, столько-то миллионов записей, отклик за столько-то миллисекунд — разговор про платформы можно не начинать. Платформы не дают гарантий такого рода, потому что они не знают, что вы на них соберёте.
Полезная стратегия при таких задачах — разделить периметр. Ядро пишут под задачу, а внутренние контуры вокруг него собирают на платформе. Экономика простая. Внутренние системы по отдельности редко оправдывают проект разработки, но вместе занимают заметную долю ресурсов ИТ-отдела.
- Публичный продукт с требованиями к отклику и отказоустойчивости, зафиксированными в договоре с клиентами.
- Собственный алгоритм, который и есть конкурентное преимущество компании.
- Уникальный интерфейс, за который платит пользователь.
- Обработка данных в объёмах, на которые платформа не рассчитана.
- Работа в контуре, куда платформа не устанавливается по требованиям безопасности.
Признак, по которому такую задачу видно заранее, простой. Если в требованиях есть число — столько-то запросов в секунду, столько-то миллионов записей, отклик за столько-то миллисекунд — разговор про платформы можно не начинать. Платформы не дают гарантий такого рода, потому что они не знают, что вы на них соберёте.
Полезная стратегия при таких задачах — разделить периметр. Ядро пишут под задачу, а внутренние контуры вокруг него собирают на платформе. Экономика простая. Внутренние системы по отдельности редко оправдывают проект разработки, но вместе занимают заметную долю ресурсов ИТ-отдела.
Российские платформы и реестр отечественного ПО
Для компаний с требованиями регулятора или с участием в госзакупках происхождение платформы становится частью технического выбора.
Реестр при этом стоит читать как фильтр, а не как оценку качества. Через него проходит большинство российского рынка, и запись говорит о формальном соответствии требованиям, но ничего не сообщает о том, подойдёт ли платформа вашей задаче.
Второй вопрос российского контекста — размещение. Для части компаний принципиально, чтобы приложение и данные жили в их собственном контуре, и здесь платформы делятся на облачные, устанавливаемые на своих серверах и работающие в обоих режимах. Уточнять это стоит до пилота, потому что переход из облака в свой контур почти всегда означает новое внедрение.
Про размер рынка. Российский сегмент low-code и no-code оценивают в 9–13 млрд рублей по 2025 году с прогнозом около 30 млрд к 2030-му, а доля отечественных решений в нём растёт примерно с 35 до 55 процентов. Для выбора платформы эти цифры мало что значат, зато объясняют, почему предложений на рынке становится больше и разбираться в них приходится самостоятельно.
Платформа | Что представляет | Реестр отечественного ПО |
ELMA365 | Low-code платформа для моделирования и исполнения процессов, микросервисная архитектура, есть ELMA AI для заполнения и проверки документов | Есть |
BPMSoft | Low-code платформа группы ЛАНИТ, исторически сильная логика CRM | Есть, запись №17372 |
Comindware | Старшая редакция объединяет BPMS и инструменты управления корпоративной архитектурой | Есть |
nocode.ru | Платформа группы Artsofte, резидента «Сколково»; конструктор форм с 30 типами контролов, графический редактор процессов, встроенная электронная подпись, API-коннекторы | Есть |
Directual | Full-stack no-code с акцентом на данные и API, около 30 000 пользователей | Нет |
AppMaster | No-code с экспортом исходного кода приложения | Нет |
Реестр при этом стоит читать как фильтр, а не как оценку качества. Через него проходит большинство российского рынка, и запись говорит о формальном соответствии требованиям, но ничего не сообщает о том, подойдёт ли платформа вашей задаче.
Второй вопрос российского контекста — размещение. Для части компаний принципиально, чтобы приложение и данные жили в их собственном контуре, и здесь платформы делятся на облачные, устанавливаемые на своих серверах и работающие в обоих режимах. Уточнять это стоит до пилота, потому что переход из облака в свой контур почти всегда означает новое внедрение.
Про размер рынка. Российский сегмент low-code и no-code оценивают в 9–13 млрд рублей по 2025 году с прогнозом около 30 млрд к 2030-му, а доля отечественных решений в нём растёт примерно с 35 до 55 процентов. Для выбора платформы эти цифры мало что значат, зато объясняют, почему предложений на рынке становится больше и разбираться в них приходится самостоятельно.
Сколько это стоит: из чего складывается
Прайсы платформ устроены по-разному, и сравнение по цене подписки почти всегда вводит в заблуждение. Смотреть стоит на четыре составляющие.
Самая частая ошибка сравнения — считать только первые две строки. Платформа с низкой лицензией, которая требует внедренца на каждое изменение, обходится дороже платформы с высокой лицензией, где изменение делается внутри компании.
Считать удобно на горизонте трёх лет и в двух сценариях. В первом всё идёт по плану — берём лицензию, первую сборку и обучение. Во втором происходит то, что происходит всегда: штат вырос на треть, процессов стало вдвое больше, а один из обученных сотрудников ушёл. Разрыв между двумя сценариями и есть настоящая цена выбора, и он у платформ отличается сильнее, чем стоимость лицензии.
- Лицензия платформы. Считается по пользователям, по приложениям или по объёму данных. Модель важнее суммы, потому что она определяет расходы при росте.
- Первая сборка. Своими силами, силами вендора или внедренца — разница в разы.
- Квалификация. Обучение сотрудников или наём человека, который знает платформу. Эта строка почти всегда пропускается в расчётах.
- Изменения. Стоимость типовой правки, умноженная на то, сколько раз в год у вас меняются процессы.
Самая частая ошибка сравнения — считать только первые две строки. Платформа с низкой лицензией, которая требует внедренца на каждое изменение, обходится дороже платформы с высокой лицензией, где изменение делается внутри компании.
Считать удобно на горизонте трёх лет и в двух сценариях. В первом всё идёт по плану — берём лицензию, первую сборку и обучение. Во втором происходит то, что происходит всегда: штат вырос на треть, процессов стало вдвое больше, а один из обученных сотрудников ушёл. Разрыв между двумя сценариями и есть настоящая цена выбора, и он у платформ отличается сильнее, чем стоимость лицензии.
Покажем Nolan на вашем процессе
Свяжемся в течение одного рабочего дня. Без спама.
Опишите задачу — мы разберём ваш процесс и подготовим демо-приложение на его основе
1
Вы оставляете заявку и кратко описываете задачу
2
Мы разбираем процесс или ЧТЗ
3
Показываем демо работающего приложения
Наши продукты:
Программа для ЭВМ «Nolan»
Программа для ЭВМ «CDP.Light»
Программа для ЭВМ «Корпоративный портал»
Компания «Технологии возврата»
3 года занимается разработкой и развитием ИИ
Из описания — в готовое приложение