# Low-code в enterprise-проектах

Canonical: https://www.kt-team.ru/blog/low-code-as-a-solution-for-enterprise-projects

Source: https://www.kt-team.ru/blog/low-code-as-a-solution-for-enterprise-projects

Canonical URL: https://www.kt-team.ru/blog/low-code-as-a-solution-for-enterprise-projects

Original URI: /blog/low-code-as-a-solution-for-enterprise-projects

## SEO / GEO Metadata

- Title: Low-code для Enterprise-проектов: возможности и ограничения подхода
- Description: Как использовать low-code платформы в Enterprise-проектах: преимущества подхода, ограничения, сценарии применения и лучшие практики интеграции в корпоративный IT-ландшафт
- Canonical: https://www.kt-team.ru/blog/low-code-as-a-solution-for-enterprise-projects
- Robots: not specified
- Open Graph tags: 4
- Twitter tags: 4
- JSON-LD blocks: 2

## Layout Blocks

<!-- blockType: navigation; selector: div -->

### ИИ / AI

AI решения инструменты кейсы карьера +7 (495) 204-14-33 Стать клиентом

---

<!-- blockType: hero; selector: div -->

### Правда ли, что low-code нельзя применять в enterprise-решениях

Правда ли, что low-code нельзя применять в enterprise-решениях разбираемся с основными возражениями 2.4.2021 Сегодня мы разберём основные возражения по использованию low-code систем у бизнеса масштаба enterprise и выясним, насколько они справедливы. ‍ Немного о парадигме low-code Возражение № 1. «Наши процессы слишком специфичны» Возражение № 2. «Лицензии на low-code системы дорого стоят» Возражение № 3. «Всё в облаке, это небезопасно» Возражение № 4. «Концепция low-code не предназначена для highload-проектов» Для каких проектов не подходит low-code ‍ Время на прочтение: 9 мин. Привет. Я Андрей Путин, управляющий партнёр ИТ-интегратора kt.team. В последнее время мы всё чаще предлагаем своим крупным клиентам использовать в ИТ-архитектуре low-code решения. Их функционал позволяет быстро вносить изменения в интеграции и бизнес-процессы. Это критично для бизнеса, учитывая динамику изменений на рынке. Forbes называет low-code трендом в первых строчках, в пользу использования low-code говорит статистика IDC, а низкая скорость изменений при традиционной разработке несёт угрозу бизнесу. Но несмотря на всё это, бизнес масштаба enterprise с осторожностью и даже недоверием относится к парадигме low-code. По мнению его представителей, прикладную разработку для крупных компаний можно осуществлять или на коробочных решениях, или с нуля. А инструментарий low-code «не соответствует масштабам задач enterprise и не обеспечивает достаточного уровня защиты коммерческой информации». Сегодня мы разберём основные возражения по использованию low-code систем у бизнеса масштаба enterprise и выясним, насколько они справедливы. ‍ Немного о парадигме low-code Бизнес регулярно требует каких-то правок. Иногда минорных, например добавить атрибут или переместить кнопку, а иногда — более значимых, требующих разработки чего-то принципиально нового. В традиционной парадигме code-first разработкой функционала и всеми правками занимается разработчик. Проигрывают при этом все. Разработчики — потому что по мере роста проекта они всё больше занимаются минорными правками и всё меньше — переиспользуемым кодом. Бизнес — потому что вынужден ждать изменения. Нам известны случаи, когда разработчики заняты минорными доработками, а в листе ожидания компании тем временем накапливается по 50 и более проектов. В концепции low-code разработчик создаёт не конечную ценность, а конструктор для её сборки. Собирать или переконфигурировать ценность в конструкторе быстрее и проще: этим могут заниматься не только разработчики, но и бизнес-аналитики или конечные пользователи с навыками разработки (те, кого Gartner называет citizen developers). Более того, для некоторых задач такие конструкторы уже есть: например, бессмысленно делать конструктор интеграций или API , когда существуют Talend, Mule, WSO2. Каждая low-code система ориентирована на решение определённых специфичных задач: моделирование и исполнение бизнес-процессов, моделирование данных, проектирование и разработка интеграций, моделирование игр, конструирование фронтенд-интерфейсов и т. д. Концепция low-code известна с 90-х годов, но сейчас она стала особенно актуальной, поскольку позволяет сократить период time to market, ускорить разработку новых бизнес-процессов и внесение изменений в уже существующие. В low-code потребность в разработчиках для корректировок бизнес-требований минимальна. Они нужны для реализации новых элементов конструктора и для конфигурирования первичной ценности с целью проверки правильности элементов конструктора. Отсюда появляется первое возражение enterprise-бизнеса. Пришлем вам необходимые материалы или КП Напишите нам: clients@kt.team Ответим в течение 30 минут! Возражение № 1. «Наши процессы слишком специфичны» Одинаковых компаний не бывает. Одни и те же бизнес-процессы даже у компаний в одном сегменте могут быть выстроены с использованием разной логики. Поэтому нам легко понять опасения владельца продукта, что low-code конструктора не хватит для нужного ему функционала. На деле же code-first ограничивает возможности реализации специфичных процессов сильнее, чем low-code. Если вы выбираете парадигму code-first, то работаете с некой коробкой или разрабатываете эту коробку. Она насыщена определёнными сущностями, функционалом, терминами. Чем мощнее этот стартовый функционал коробки, тем сложнее будет вносить изменения в систему. Чем больше изменений вы будете вносить, тем меньше людей в принципе будут понимать, что и как работает: сложность вносимых изменений будет повышаться, и неважно, микросервисная у вас архитектура или монолитно-модульная. Ответственность за результат размоется. На претензию: «Почему вы сделали неудобно?» — разработчики будут отвечать: «Почему вы так плохо описали требования?» Разработчики утонут в change-реквестах, бизнес будет игнорировать часть требований. Команда разработки станет «бутылочным горлышком» всех изменений — следовательно, по теории ограничений вам придётся строить другие процессы с учётом этого. Частью функционала коробки вы не будете пользоваться, ещё часть будет подходить вам при адаптации бизнес-процессов под коробку. В итоге появятся новые, не свойственные вашему бизнесу термины, в ряде случаев интерфейсы управления будут избыточно сложны, в ряде случаев с какими-то нюансами придётся мириться. Да, можно возразить, что в таких продуктах — «лучшие практики». Однако эти практики могут не соответствовать текущей культуре компании, и в результате «лучшие практики» превратятся в карго-культ. Сравните это с работой в парадигме low-code. Low-code решения не предлагают «лучшие практики»: при помощи конструктора вы проектируете решение, которое максимально соответствует особенностям вашего бизнеса. При этом разработчики не сосредоточены на бесконечных минорных правках. Они занимаются новым функционалом и новыми элементами конструкторов, исследуют инженерные подходы. Разработка с каждым днём делает конструктор всё более разнообразным и удобным для бизнеса. Что же касается «лучших практик», то многие low-code решения имеют уже сконструированные приложения, например CRM или готовые интеграции. Но при этом готовые решения практически никогда не являются фиксированной системной особенностью — всё можно поменять. Уходят в прошлое возражения про системные атрибуты и сложность переопределения части коробки. Возражение № 2. «Лицензии на low-code системы дорого стоят» У low-code платформ есть несколько моделей монетизации. Например, в Talend монетизация осуществлена за счёт мест разработчиков: неважно, сколько интеграций у вас уже запущено, — важно, сколько людей работают над внесением изменений в них. При этом в контуре продуктивных серверов у вас нет лицензируемых частей. А часть решений действительно являются SaaS и оплачиваются по пользователям. Давайте разберём именно этот кейс. 1. Разное восприятие расходов на лицензии и разработку мешает объективно сравнивать их. Покупка лицензий и оплата разработки проходят по разным «центрам задач» и по-разному отражаются на экономике проекта. Это мешает сравнивать расходы на паритетных началах, в рамках проекта стоимость лицензий кажется более заметной. ‍ 2. Лицензии дешевле, чем разработка с нуля. Покупая лицензию на любой продукт — неважно, является ли он low-code, — вы платите за готовый продукт, с помощью которого будете решать задачи. Как правило, стоимость лицензии ниже, чем у проекта по созданию самописного продукта с аналогичным наполнением и функционалом. А в случае с low-code решениями риск несоответствия функционала задачам неактуален: функциональность конструктора оценить проще, чем узнать все нюансы уже готового функционала. ‍ 3. У лицензий простая экономика без фактора неопределённости. Вам сразу понятно, сколько вы заплатите за количество пользователей low-code решения. А сколько предстоит платить за разработку нового функционала, сложно предположить заранее. Ведь нужно учесть трудозатраты владельца продукта и большее время ожидания функционала, часто даже зарплаты разработчиков компании не являются частью бюджета функционала. Подробнее об экономической составляющей разработки можно почитать в статье «Вложения в ИТ». Бывает, что крупный бизнес даже не считает эти затраты, и они размываются в общем бюджете. ‍ 4. В low-code вы покупаете не только инструменты визуальной разработки, но и лучшие практики конструирования процессов. Никто не может знать, как удобнее построить бизнес-процесс в вашей организации. Но при этом есть практики реализации типовых действий, которые помогут вам выстроить более прозрачный и управляемый процесс за меньшее количество итераций. Например, low-code ESB -системы задают некоторые паттерны проектирования интеграций в части логирования, мышления терминами «поток»/«линия» и т. д. Low-code бизнес-процессы задают стандарты проектирования процессов. Разрабатывая аналогичный бизнес-процесс своими силами, вы, скорее всего, придёте к таким же практикам, но не сразу. Вспомните, например, часто ли ваши менеджеры пользуются BPMN при согласовании процессов? А использование LCAP позволяет сократить путь поиска оптимального решения в разы. Возражение № 3. «Всё в облаке, это небезопасно» Мы сталкиваемся с этим возражением довольно часто. У бизнеса вызывает опасение тот факт, что low-code решение хранится «где-то в облаке, на чьих-то серверах, мы его не контролируем». На это возражение есть несколько ответов. Во-первых, не все low-code системы обязательно разворачивать именно в облаке. Поставщики этих решений предоставляют заказчику выбор: облачное решение или решение внутри вашей экосистемы, а часть решений даже имеют открытый исходный код (Strapi, Pimcore, Corteza, Builder). Обычно лицензия для разворачивания на серверах в контуре компании стоит дороже, но такая возможность всё же есть. Во-вторых, даже облачные решения потенциально можно разместить на приватных облаках. Такую опцию, например, предлагает Power BI из экосистемы Microsoft: «ваш» Power BI может быть размещён на выделенных серверах платформы Azure, в отдельной части дата-центра. У e-Commerce low-code также есть планы, согласно которым они могут предоставлять клиентам приватные облака. Если же вы сами решили перестроить in-house разработку в low-code парадигму, то с точки зрения безопасности у вас и вовсе ничего не меняется. Возражение № 4. «Концепция low-code не предназначена для highload-проектов» Как раз напротив: многие low-code системы по умолчанию предназначены для работы с highload. Обработка тысяч запросов в секунду для них не является критичной. К таким решениям относятся, например, Talend , Honeycode, Creatio, Strapi, Pimcore. Мы замечаем обратное: часто эксклюзивная разработка, в теории предназначенная для высоких нагрузок, имеет огромный объём наследия, рефакторить которое сложно и дорого. В противовес этому многие low-code конструкторы раз за разом отлаживают скорость компонентов. Тут нужно оговориться, что low-code может избавить от многих технических проблем, но от ошибок проектирования информационных моделей, бизнес-процессов и прочего, что также влияет на итоговую производительность, не избавлена ни концепция low-code, ни парадигма code-first. Один нюанс: не всегда у бизнеса есть корректное представление о том, что такое highload. Он обращается к ИТ-подрядчику с запросом на высоконагруженный проект, но на практике оказывается, что речь идёт о крупном подразделении с серьёзным оборотом. Например, B2B-портал, который обслуживает 3000 клиентов в день, или B2C интернет-магазин с миллионом посетителей в месяц даже не приближается к тому, что принято считать highload. Тут нет десятков тысяч одновременных сложных транзакций на запись и, скорее всего, в ближайшей перспективе не будет. Пока ваш проект не подошёл к условной границе в 5000 транзакций в секунду, рано беспокоиться о том, поддерживают ли выбранные системы highload. Лучше сконцентрироваться на других вопросах и бизнес-целях. Но даже если у вас действительно highload-проект, это не исключает возможности применения low-code. Мы знаем достаточно крупные экосистемы, которые построены из небольших «кусочков». Например, у «Тинькофф» есть множество отдельных BPMS (Camunda), каждая из систем работает со своим набором бизнес-процессов. Это сделано не столько потому, что выбранное решение «не потянет» highload, сколько для лучшего контроля и отказоустойчивости. Для каких проектов не подходит low-code Концепция low-code достаточно универсальна. Да, для выбора конкретного решения нужно изучить его возможности и аналоги, но в этом low-code не отличается от других концепций. Однако есть ситуации, когда сама концепция low-code может не подходить бизнесу. ‍ 1. Если вы готовы подстраиваться под существующую коробку. В этот пункт обычно попадают второстепенные бизнес-процессы и любые «пассивы». Например, какая разница, как гибко у нас начисляется зарплата или конфигурируется СКУД, если у этой гибкости нет никакого мультипликатора для бизнеса? 2. Разработку принципиально новых (инновационных) технологических решений в ряде случаев нельзя реализовывать в философии low-code. Важно понимать, что здесь идёт речь именно о технологических инновациях, а не инновациях в области бизнес-моделей. 3. Если вы ИТ-команда и вам сложно переучивать сотрудников на новый уровень абстракции, а дальнейшее сопровождение и внесение изменений в проект не подразумеваются. 4. Если у вас нет времени на перестройку (проект нужно запустить «вчера») или вы сталкиваетесь с огромным наследием старого кода. 5. Если у вас нет выбора. Например, вы часть корпорации, а набор технологий задан сверху. Так, много штаб-квартир используют Magento как стандарт e-Commerce, и региональные офисы тоже вынуждены использовать Magento . 6. Если вы хотите сохранить статус-кво и любые изменения парадигмы идут вразрез с вашими целями. Пришлем вам необходимые материалы или КП Напишите нам: clients@kt.team Ответим в течение 30 минут! Оглавление Немного о парадигме low-code Возражение № 1. «Наши процессы слишком специфичны» Возражение № 2. «Лицензии на low-code системы дорого стоят» Возражение № 3. «Всё в облаке, это небезопасно» Возражение № 4. «Концепция low-code не предназначена для highload-проектов» Для каких проектов не подходит low-code Другие статьи Смотреть все Честный ЗНАК и 1С интеграция для маркировки 26/8/2025 Подробнее Как IT-консалтинг и современные решения по кибербезопасности помогают защитить бизнес от внешних и внутренних угроз 22/11/2024 Подробнее Облачная трансформация как стратегический инструмент цифровой трансформации бизнеса в эпоху облачных технологий 12/8/2025 Подробнее Мы используем файлы cookie, чтобы предоставить наилучшие возможности сайта Ок Давайте обсудим ваш проект С вами свяжутся персональные менеджеры clients@kt.team Email: @kt_team_it Telegram: О нас Услуги Кейсы Блог Карьера Основы ценообразования Бизнес-стажировка Отзывы PIM/MDM-системы ESB-интеграции DevOps Low-code Микросервисы B2B-порталы и e-commerce PWA Magento Калькулятор проекта Unit-экономика © 2026 ООО «КТ Групп» ООО «КОМПЛИЦЕРТЕ ТЕХ» Komplizierte Technologien, GmbH Россия Тольятти, ул. 40 лет Победы, 41 Москва, Романов переулок, 2с1, пространство Noodome clients@kt.team +7 (495) 204-14-33 Положение о работе с персональными данными →

![image](/assets/original/68adb246ce2a6657a645ec3acover42-a454b55568.avif)
![Как IT-консалтинг и современные решения по кибербезопасности помогают защитить бизнес от внешних и внутренних угроз](/assets/original/kak-it-konsalting-i-sovremennye-resheniya-po-kiberbezopasnosti-pomogay-071ee38ecc.avif)

---

<!-- blockType: footer; selector: footer -->

О нас Услуги Кейсы Блог Карьера Основы ценообразования Бизнес-стажировка Отзывы PIM/MDM-системы ESB-интеграции DevOps Low-code Микросервисы B2B-порталы и e-commerce PWA Magento Калькулятор проекта Unit-экономика © 2026 ООО «КТ Групп» ООО «КОМПЛИЦЕРТЕ ТЕХ» Komplizierte Technologien, GmbH Россия Тольятти, ул. 40 лет Победы, 41 Москва, Романов переулок, 2с1, пространство Noodome clients@kt.team +7 (495) 204-14-33 Положение о работе с персональными данными →
