Разработка
GlowByte

Почему Low-code плохо приживается

Привет, vc.ru. Меня зовут Георгий Ржавин. Я работаю процессным архитектором в компании GlowByte, руковожу направлением Business Process Management. В этой статье хочу обсудить основные причины неэффективности современного лоукода и, основываясь на своих наблюдениях, обозначить пути решения проблемы.

Разбираемся в терминах

Для начала давайте разберёмся в понятиях. Любой современный бизнес не мыслит себя без сильного ИТ. Яркий пример – банки, которые представляют собой ИТ-компании с тысячами разработчиков на борту. При этом данный ресурс остаётся для компаний в дефиците: ИТ-подразделения, как правило перегружены, задачи распланированы на месяцы вперёд. Вот так плавно мы с вами подходим к термину Low-code. В действительности Low-code – это попытка сместить тяжесть разработки с ИТ в сторону бизнеса. Сместить на сам бизнес ещё не получилось, но, по крайней мере, появились проекты, где 80 % всех работ закрывают бизнес-аналитики (не ИТ-специалисты). Именно такие проекты мы и будем в рамках данной статьи называть Low-code.

Ещё одно уточнение. Low-code-подходы распространились достаточно широко – от создания сайтов и мобильных приложений до автоматизации бизнеса. В рамках данной статьи реализация Low-code-подхода будет рассмотрена на примере систем класса BPMS (Business Process Management Suite).

Проблематика

Если ещё лет 5 назад на конференциях можно было услышать вопросы: «А вы верите в Low-code?», «Неужели не ИТ-специалист может что-то, пускай даже небольшое, сам автоматизировать?». Сейчас такой проблематики уже нет, Low-code прочно вошёл и обосновался на российском рынке. Подтверждением тому являются конференции, полностью посвящённые Low-code-инструментам. Но возникла другая проблема – низкая эффективность Low-code-проектов. Нет тех скоростей, которые нам обещали с появлением этого подхода.

Лоукод лоукоду рознь

Для начала давайте развеем одно из заблуждений. Low-code – это не набор параметров или обязательных инструментов, при наличии которых система получает это звание. Здесь правильней рассмотреть некую горизонтальную шкалу, в левой части которой находится классическая разработка, а в правой – No-code-проекты, когда 100 % работ может закрыть не ИТ-специалист, не написав при этом ни одной строчки кода. Всё остальное пространство между этими двумя крайними положениями занимают Low-code-инструменты. При этом кто-то из вендоров «ушёл» дальше и приблизился к No-code-инструментам, а у кого-то Low-code-инструментарий очень скромный и любой проект требует написания кода.

Рассмотрим в данном примере две системы класса BPMS: Bizagi и ELMA 3 (4). В первой аналитик может самостоятельно в конструкторе собрать пользовательскую форму, а также сделать её динамической (скрывать или показывать поля в зависимости от действий пользователя системы), и всё это настраивается с помощью мышки, без кода. В ELMA так же есть конструктор, позволяющий собрать пользовательскую форму, но вот для добавления динамики уже придётся писать код на внутреннем сценарном языке – на базе C#.

Поэтому две системы одного и того же класса в зависимости от функционала и объёма Low-code будут «выдавать» разные скорости разработки и требовать разный состав команд. Но об этом чуть позже.

На рынке нет нужных кадров

Давайте ещё раз вернемся к основной идее (и даже причине) появления Low-code – попытке сдвинуть «тяжесть» разработки с ИТ-специалистов на не ИТ-специалистов. Это случай, когда ожидание не совпало с реальностью, потому что зачастую я наблюдаю в командах, работающих с BPMS, преимущественно разработчиков, причём, как правило, очень злых и всё время чем-то недовольных. И их можно понять, их заставляют автоматизировать процессы в каком-то миксе мышки и привычного для них кода. Они искренне не понимают, зачем им в дополнение к знанию языков программирования изучать некий инструмент мышкования, почему нельзя писать на современной версии языка (как правило, когда до нас доходит BPMS, версия языка, который она поддерживает, устаревает). Почему нельзя использовать всю мощь современной разработки (git, отладка и т.д.). Ради чего всё это было принесено на алтарь Low-code.

При этом аналитиков, для которых и создавался этот инструмент, зачастую к нему не подпускают. Подход к разработке не меняется. Аналитик, как и прежде, создаёт и описывает систему на бумаге, а уже на основе ТЗ разработчики в BPMS автоматизируют процессы, в том числе с помощью Low-сode-инструментов.

Похоже на теорию заговора: разработчики не хотят делиться пирогом с аналитиками и не пускают их к инструменту. Но оказывается всё намного проще. Дело в том, что построить модель процесса, пригодную для BPMS, – это совсем не то же самое, что создать модель процесса для согласования с бизнесом и (или) для вставки в процессный регламент. Аналитическая схема процесса может содержать ошибки, при этом читатель схемы что-то может домыслить, а что-то будет уточнено в комментариях на схеме. Это, конечно, супер не правильно, если ваша схема содержит ошибки и нарушает стандарт, но это не мешает эту схему обсуждать с другими участниками и даже вставлять её в регламент. Да даже ходить с ней на конференцию наличие ошибок не является препятствием.

А вот «скормить» её BPMS при наличии ошибок не получится. Поэтому самое первое требование к исполняемой схеме процесса – это соответствие стандарту BPMN 2.0. С последним у аналитиков в России большие проблемы, потому что нотацию изучают в основном стихийно, на практике, не обращаясь к первоисточнику. Как результат – создать модель процесса, которую поймёт и домыслит разработчик, любой аналитик может, а вот построить модель без ошибок, согласно стандарту, практически нет. Таких на рынке единицы, ну, может быть, десятки. Сейчас меня могут закидать помидорами, но, поверьте мне, я знаю о чём говорю, так как сам являюсь представителем аналитиков, хожу на профильные конференции, общаюсь с коллегами по цеху.

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

Шурупы надо закручивать, а не забивать

Ещё одну характеристику, которую нам обещали в Low-code BPMS, – высокую скорость внесения изменений – мы также где-то во время внедрения этих инструментов теряем. И это действительно так, это не обман маркетологов. Доказательством этого явления была следующая картина, которую я наблюдал в крупной организации. Одна команда вносила изменения в текущие автоматизированные процессы за часы, а другая, на таком же инструменте, но на соседнем сервере, – дни. После анализа ситуации стало ясно, что вопрос не в компетентности сотрудников, а в архитектуре итогового решения. Дело в том, что на старте обоих проектов каждой из команд была вручена система в одном и том же состоянии, а дальше одна из систем растеряла все свои лоукод-инстурменты и по сути представляла монолит с оболочкой BPMS. В результате в первой команде аналитик заходил в конструктор форм, добавлял кнопку с помощью мышки, «вешал» в её настройках необходимое поведение. А второй команде для достижения такого же результата нужно было анализировать код пользовательской формы, добавлять туда кнопку, а далее всё тщательно тестировать. В первом случае всю дополнительную работу делала Low-code-система.

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

Поделюсь собственным примером. В рамках создания кредитного конвейера для МСБ все интеграции мы старались делать универсальными, в виде чёрных ящиков, причём как входные параметры, так и выходные настраивались аналитиком, без необходимости вносить изменения в код интеграции. В результате уже после завершения проекта мы щедро поделились этими наработками с другими, ранее автоматизированными процессами. Например, часть интеграций пригодилась для корпоративного бизнеса и их процессов. Причём интеграция новых кубиков занимала ровно три дня: один день на тест, второй – на препрод, третий – на боевой сервер. В дальнейшем, при сборке (автоматизации) очередного кредитного конвейера для МСБ, мы значительно сократили трудозатраты и сроки на его реализацию, так как в большей степени собирали его из готовых кубиков, в меньшей степени прибегая к разработке с нуля. В результате на выходе получили следующую математику: всего три дня на подключение против месяца повторной разработки каждого из сервисов.

Баланс при работе в BPMS найти легко. Достаточно соблюдать следующий набор правил:

1. Приоритизация стандартных объектов системы перед кастомными.

2. Если нужного функционала нет, разрабатываем свой, но обязательно стараемся делать его универсальным. Тем самым обогащаем конструктор новыми «кубиками» для последующей работы.

Идеальный проект

В конце статьи хотел бы описать идеальный проект по внедрению BPMS, к которому нам надо стремиться:

1. Тщательный выбор BPMS. Подскажу один лайфхак. Попросите вендоров BPMS автоматизировать небольшой процесс прямо во время демонстрации продукта. Так вы сможете прорваться через маркетинговые картинки и на практике увидеть, насколько лоукодистой является рассматриваемая система. Ну а если у вас сформированная команда разработчиков и именно они будут заниматься автоматизацией, то я вам рекомендую в первую очередь посмотреть в сторону BPM-engine (Camunda, Activiti). Разработчики вам только спасибо скажут.

2. Формирование команды. Обязательно включайте в команду процессных аналитиков и правильно распределяйте полномочия. В Low-code-инструментах работать должны в первую очередь аналитики. Не прощайте аналитикам схемы в нотации BPMN 2.0 с нарушениями стандарта. При необходимости отправляйте их на обучение.

3. Играйте по правилам BPMS. Если выбрали данный инструмент, обязательно изучите его и старайтесь играть по правилам. Не нужно сломя голову реализовывать любой каприз бизнеса. Я наблюдал такую картину, когда в проекте полностью отказались от конструктора пользовательских форм (увеличив трудозатраты на автоматизацию в разы, если не в десятки раз) только из-за требования бизнеса разместить вкладки на форме вертикально (в конструкторе можно было только горизонтально). Самое интересное то, что при повторном согласовании дизайна выяснилось, что бизнесу никто не предлагал реализовать по-другому, более того, данное требование не было критичным и можно было вполне остаться в рамках конструктора.

Не так плох Low-code, если умеешь его правильно "готовить”!

0
19 комментариев
Написать комментарий...
Vlad Radis

Отличная статья! Полностью разделяю подход автора.

Ответить
Развернуть ветку
GlowByte
Автор

Влад, спасибо!

Ответить
Развернуть ветку
Игорь Нестеров

А какой low code инструмент лучше изучать аналитику для выхода на международный рынок? Наверное про ELMA мало кто слышал за пределами РФ. При этом Camunda это все таки движок. До прихода в аналитику, я работал 1с программистом, где тоже много low code инструментов. Теперь вот скучаю по разработке и думаю попробовать low code, но все инструменты какие-то малоизвестные.

Ответить
Развернуть ветку
Michael Golovastikov

Microsoft Power Platform

Ответить
Развернуть ветку
GlowByte
Автор

Здравствуйте!
Если зарубежный рынок интересует, то попробуйте инструмент наших бразильских коллег - https://www.heflo.com/
Достаточно лоукодистая система. Хорошая поддержка BPMN2.0

Ответить
Развернуть ветку
Игорь Нестеров

Спасибо. Но если провести эксперимент и в linkedin поискать HEFLO в вакансиях, то результат пустой. Возможно, пригодится для ознакомления конечно, но применить такие знания в поиске вакансий будет трудновато)

Ответить
Развернуть ветку
GlowByte
Автор

Тогда Bizagi, но, в отличие от Heflo, они перестали с нами дружить. Хотя онлайн-обучение у них отличное. Я думаю при определённой сноровке вы до них доберётесь. )

Ответить
Развернуть ветку
sles

"Сейчас такой проблематики уже нет, Low-code прочно вошёл и обосновался на российском рынке." сказки про самопишущийся софт я слышу с 1993 года, когда к нам приезжал професур из калифорнийского университета ( еврей, когда-то учившийся в нашем петеу ) . Прогресс с тех пор ровно 0.

Ответить
Развернуть ветку
GlowByte
Автор

Здравствуйте!
Спасибо за комментарий.
У меня есть ролик, где я за 15 минут с помощью мышки автоматизирую процесс. Лучше 1 раз увидеть, чем 100 раз услышать:)

https://www.youtube.com/watch?v=NBxVGPLkVFI

Ответить
Развернуть ветку
Nikolai Syrvachev

Здравствуйте.
Самое печальное, что создатели подобных перлов "бизнес процессов" даже не понимают, что и зачем они делают.

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

По сути, подобный "бизнес процесс" нужен только создателю бизнес процесса.

Было: На заготовленном бланке заявления сотрудник вписал свои ФИО и даты отпуска, после чего подписал у руководства и отдал в HR-отдел. Занимает 3 минуты.

Стало: бессмысленный "бизнес процесс", в результате которого все-равно надо идти подписывать это заявление у руководства и нести в HR-отдел.

Зачем это все ?)

Что бы инструмент был реально рабочим, его придется привязать к CRM и Бухгалтерии, в чем бы она ни была. Но решить методами Low-code даже такую простую задачу, как заявление на отпуск... мда...

Ответить
Развернуть ветку
GlowByte
Автор

Здравствуйте!
Если вы про процесс из ролика, то он учебный. Как "Hello World", не более. Его цель продемонстрировать на практике возможности подобных систем, причём сделать это без часового просмотра ролика.
Если говорить про рекорды боевых процессов, то в нашей команде это 4 часа на реализацию курьерской службы для строительной компании.

Ответить
Развернуть ветку
sles

Глянул мельком/
Вижу всё ровно то же, те же по сути блок-схемы, хотя и в ином виде.
Всё это уже было, тот же UML вспоминается с генерацией кода.
И всё это умерло. Типичное развитие по спирали, вряд ли когда взлетит.

Ответить
Развернуть ветку
Brak Brako

Да уж, тоже посмотрел, выглядит конечно очень просто для супер быстрых нужд какой-либо компании(у которой небольшой штат сотрудников или бюджет маловат), но боюсь скорость работы системы оставляет желать лучшего.
А если вдруг все слетит(имеется в виду ошибка программы например), кто фиксить будет тоже непонятно. Тетя Зина там будет очень сильно охать и спрашивать «а что же делать? не работает же»

Ответить
Развернуть ветку
GlowByte
Автор

"А если вдруг все слетит(имеется в виду ошибка программы например), кто фиксить будет тоже непонятно" - всё точно так же, как при внедрении коробочных решений. Если слетело из-за собственных поделок - исправляешь сам. При этом, т.к. работает не IT-специалист, в подобных системах очень много расставлено заглушек, чтобы аналитик не выстрелил себе в ногу. А если сломалось что-то в самом решении, идём к вендору.

Ответить
Развернуть ветку
Brak Brako

Кому-то все же придется писать Лоу-код программы для аналитиков, так что рыночек может и будет пользоваться спросом на ваше «лоу-код», но также будет больший спрос на тех, кто эту систему будет писать, поддерживать и обновлять :) Так что господа, поздравляю, программисты теперь не будут торчать в офисе и загибаться от выполнение одних и тех же действий изо дня в день, а будет вам профессиональное развитие и интерес, да и понимание будет существовать (хоть какое-то)

Ответить
Развернуть ветку
Иван Крючков
не написав при этом ни одной строчки кода
её динамической (скрывать или показывать поля в зависимости от действий пользователя системы), и всё это настраивается с помощью мышки, без кода

Вы просто заставили аналитиков программировать, если вы натыкаете условие мышкой, вместо if (a == b), это не перестанет быть программированием.
Есть ещё проблема, что абстракции имеют свойство "протекать" https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/. Аналитикам придется разбираться как внутри все устроено, в результате все равно людям придется приобретать необходимые знания или обращаться к тем у кого есть знания эти.

Ответить
Развернуть ветку
GlowByte
Автор

Позволю с вами не согласиться.

Во-первых, сейчас почти всё программирование завёрнуто в определенный уровень абстракций. Для создания веб-сервиса берут готовую библиотеку, при этом разработчик может и не знать, что такое сокет. Разработчикам это не мешает, почему будет мешать аналитикам?

Во-вторых, дело не в том, чтобы заставлять кого-то. Тогда действительно смысла бы никакого в этом не было. Какая разница, аналитик занимается автоматизацией или разработчик. На выходе за привлечение специалиста платит бизнес и ему всё равно, как зовут специалиста. Дело немного в другом. Если упростить модель, то классическая цепочка выглядит следующим образом: бизнес -> аналитик -> разработчик. Передача требований - это время и искажения. А при работе в лоукоде, цепочку можно сократить до: бизнес -> аналитик.

Конечно всему этому есть цена - некие ограничения, в рамках которых работает аналитик.

Ответить
Развернуть ветку
Иван Крючков

Кроме сокетов и модели OSI, есть более высокие слои абстракций, например внутренняя реализация платформы, которая bpmn схему и исполняет во плоти. Все равно кроме бизнеса надо знать что-то ещё. Само понятие "создать форму" уже не относится только к бизнес домену. Ваша изначальная концепция "сместить сложность с IT на бизнес" не работает. Есть IT, есть бизнес, от перемены мест слагаемых ничего не изменяется. Есть работа, ее надо в любом случае выполнить, чтобы случилась автоматизация, вы ее таскает туда сюда с одной должности на другую.

Ответить
Развернуть ветку
GlowByte
Автор

Есть известная фраза: "Господь Бог создал людей, президент Линкольн дал им свободу, а полковник Кольт сделал их равными". Здесь, мне кажется, похожая история. Раньше средний и малый бизнес стоял в сторонке, ему вся эта автоматизация была недоступна. Можно было только купить некую коробку и адаптироваться под нее, а не она под тебя. А теперь рынок стал ровнее. Я например, наблюдал такую картину, когда банк из третьей сотни (с соответствующими бюджетами), автоматизировал процесс по открытию счета ИП(ЮЛ), а в рамках независимого исследования MarksWebb, данный процесс занял первые места по ряду потребительских качеств, подвинув топовые банки с бюджетами в 100 раз больше. В основе решения как раз была отечественная BPMS и все работы были выполнены аналитиком. Позволить себе мало-мальскую команду по созданию похожего функционала классической разработкой банк попросту не мог себе позволить.

А по поводу знаний, я с вами согласен. Плох тот аналитик, кто не знает что такое endpoint и что такое Postman.

Ответить
Развернуть ветку
Читать все 19 комментариев
null