Что не так с low-code в крупных компаниях?

С ростом организации усложняется ее структура, меняются ключевые бизнес-процессы. Чтобы оперативно подстраиваться под новые стандарты, корпоративный ИТ-ландшафт должен быть достаточно гибким. Сегодня именно low-code-разработка считается решением, которое может ускорить и удешевить адаптацию корпоративных систем к новым условиям и требованиям.

Сергей Скурыгин, руководитель направления разработки Directum

И выглядит все вполне многообещающе: бизнес самостоятельно справляется с теми задачами, которые не требуют написания кода, не тратит время на обучение специалистов, не инвестирует в высококвалифицированных разработчиков и может оперативно тестировать на практике новые теории без написания кода. Вопрос в том, всегда ли применим «малокодовый» подход к сложной бизнес-логике внутренних процессов больших предприятий?

Последние несколько лет low-code и no-code не выходят из цифровых трендов на российском рынке. Эти термины прочно вошли в обращение, но вот трактуют их все по-разному.

Давайте разбираться, насколько универсальна история с low-code, когда речь идет о больших предприятиях. При выборе ИТ-продуктов крупные компании учитывают множество факторов:

Все low-code-платформы одинаково неуниверсальны

Платформы «малокодовой» разработки вполне пригодны для решения бизнес-задач компаний. Чаще всего — отдельных небольших процессов, для которых некритичны требования к масштабируемости и UI/UX. Если применять low/no-code к сложным процессам с витиеватой бизнес-логикой, есть риск резко «разлюбить» эту концепцию.

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

Возьмем, к примеру, кадровые процессы, которые по умолчанию присутствуют в компаниях любого масштаба. Прием сотрудников, организация отпусков, генерация различных заявлений — казалось бы, типовые для всех задачи. В реальности только чтобы обеспечить сотрудников доступом к системе, нужно разработать и внедрить сразу несколько интерфейсов с разным набором фич в зависимости от роли пользователя: кадровика, руководителя, «рядовых» работников.

При детализации выясняется, что практически в любом направлении работы крупной компании есть множество нюансов, которые должны находить отражение в ИТ-системах. Процесс, как его понимает тот же BPM, — это лишь часть большой бизнес-задачи.

Low-code-платформа (не) требует обучения

Не требуй low-code обучения, это значительно бы облегчило жизнь многих компаний. Но на практике схема не работает даже если у вас есть грамотный аналитик, отлично знающий «внутрянку». Да, с конкретной настройкой такой специалист справится без сложного и длительного обучения. Но это только первый уровень, который ограничен, например, изменением конкретного блока в бизнес-процессе или добавлением новых полей в карточку документа.

Еще одна проблема – смешение настройки и разработки в одном интерфейсе, когда и то, и другое доступно аналитику. Это повышает требования к специалистам и несет риски для стабильности системы.

Глубокая настройка – создание новых блоков, веток процесса, форм, справочников и пр. – требует детального погружения в платформу. Без знаний не получится найти оптимальное решение. Когда этими работами занимается не разработчик, могут появляться ненужные сущности, усложняется интерфейс, а работа дорожает — явно не этого эффекта ожидает компания от low-code-платформы.

Low-code = легкое внедрение?

Малая автоматизация процессов небольшой компании — вполне под силу low-code-платформам. Достаточно реализовать MVP, подготовить прототип, и можно запускать программный продукт в работу.

Если речь идет о масштабных задачах для тысяч пользователей – вряд внедрение будет легким. Понадобится тщательно проанализировать бизнес-процессы, привлечь ресурсы на адаптацию и тестирование — это и трудоемко, и дорого. Неужели low-code возглавил то, с чем должен был бороться?

Low-code и no-code против масштабируемости

Гибкость и адаптируемость важны для крупных компаний, сомнений в этом нет. Причем требования по легкости настройки универсальны для всех классов систем, они касаются процессов, интерфейса, документов, интеграций и пр. Это базовое требование к информационным системам (ECM, CRM, BPM, SRM, HRM и т.д.).

А что с масштабируемостью? Low-code-конструкторы обычно мешают производительности на больших масштабах. Дело в том, что характерные для «малокодовых» платформ динамические вычисления и структуры данных дают большой объем лишних операций, которые снижают быстродействие системы.

Есть вариант решения этой проблемы. Если выделить no-code и low-code в разные уровни системы, можно сохранить масштабируемость системы без ущерба быстродействию.

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

1. Настройка (no-code). Здесь рулит аналитик, который не погружается в код, но может оперировать вычислениями и создавать достаточно сложные процессы. При необходимости он же может скорректировать и интерфейс. Например, создать сценарий обработки нового вида заявки или поменять состав полей на форме.
2. Разработка (low-code). Когда аналитику не хватает возможностей, он обращается к разработчику, который будет работать в low-code-среде — создавать специальные блоки и функции, например, коннекторы, интеграционные сценарии, а аналитик — добавлять их в схему процесса одним кликом.

Одновременно все это строится на мощной платформе, которая разработана под специфику работы с документами и процессами. Именно в такой концепции мы развиваем систему Directum RX.

Редактор схем

Благодаря тому, что в Directum RX разные модули работают на одной платформе, компания выстраивает единую ИТ-экосистему. Развитие системы, ее оптимизация и кроссплатформенность остаются ответственностью вендора. Поскольку многие бизнес-задачи уже полноценно реализованы в решениях, упрощается первоначальная настройка, и стартовать работу можно раньше.

Вместо вывода

Low-code действительно закрывает ряд потребностей крупного бизнеса, но важно четко разделять настройку и разработку. Безопаснее оставить сложную логику и программирование компетентным разработчикам, при этом простую настройку можно делегировать аналитикам. Каждый должен заниматься своим делом в зависимости от уровня компетенций. Никому не хочется столкнуться с ситуацией, когда работоспособность системы, которую используют тысячи сотрудников, снижается, потому что аналитик случайно «залез» в код.

Благодаря удобной настройке и готовым решениям аналитик закрывает многие задачи самостоятельно, не прибегая к помощи разработчика. В своей практике мы убедились, что такой подход действительно ускоряет запуск системы. Что важно – снижается трудоемкость стартовой адаптации.