Георгий Ржавин, Ассоциация профессионалов управления бизнес-процессами: «После тотального кодирования в Low-Code платформе от нее остается лишь оболочка»

Георгий Ржавин, вице-президент по обучению, Ассоциация профессионалов управления бизнес-процессами, и спикер Конференции «Оптимизация бизнес-процессов в банках», рассказал CFO Russia о преимуществах и особенностях Low-Code автоматизации, а также разобрал одну из серьезных ошибок при работе с Low-Code платформой.

Что такое Low-Code автоматизация?

Всем известна пропасть между ИТ и Бизнесом – каждый из них говорит на своем языке. Отсюда – желание ИТ передвинуть разработку со всей ее тяжестью поближе к Бизнесу. Отсюда же – необходимость и появление такой профессии, как бизнес-аналитик – мостик между Бизнесом и ИТ. Передать разработку Бизнесу пока не получилось, а может и не получиться никогда. Зато получилось научить бизнес-аналитиков автоматизировать процессы. Появились инструменты, которые позволяют аналитику самостоятельно выполнять многие недоступные до этого задачи: переложить объектную модель в базу данных, без единой строчки кода создать пользовательскую форму, которая корректно будет работать и на персональном компьютере, и на планшете, и на мобильном телефоне, и т.д. Все эти инструменты и сам подход принято называть – Low-Code.

Для каких процессов применяется Low-Code и какие задачи можно решить с его помощью в банковской сфере?

С помощью Low-Code можно автоматизировать любые процессы. Конечно, я бы не стал автоматизировать высоконагруженные конвейеры. С другой стороны, термином «высоконагруженный» многие злоупотребляют. Если у вас в процессе половина задач выполняется людьми, он априори не может считаться высоконагруженным.

Какой конвейер можно считать высоконагруженным и почему его не стоит автоматизировать?

10, 100 запусков процесса в секунду – это не высоконагруженный. Несколько тысяч в секунду – уже можно считать высоконагруженным.

Почему не стоит автоматизировать: при прочих равных (количество пользователей системы, требования к нагрузке, требования к серверу) конвейер на базе Low-Code платформы работает медленнее, чем при классической разработке.

А с чем еще справляется Low-Code?

Еще один класс задач, с которым легко может справиться Low-Code BPMS, – это создание прототипов и тестирование различных бизнес-идей. Преимущество этого инструмента здесь – короткий срок от идеи до работающего прототипа.

Приведите, пожалуйста, примеры классических ошибок в проектах по Low-Code автоматизации процессов. Какие инструменты/подходы использовать, чтобы минимизировать риски таких ошибок?

Ответ на этот вопрос тянет на целое выступление. Ошибок очень много. В основном они связаны с тем, что многие команды, которые ранее внедряли CRM, ERP и т.д. и/или занимались классической разработкой, применяют те же методы, подходы и инструменты при автоматизации в Low-Code платформах.

Например, в проект, где ядром является Low-Code платформа, включают разработчиков, а про аналитиков либо забывают, либо оставляют им классические задачи по формированию требований, не допуская к работе в системе. В результате разработчики мучаются и борются с системой. Им кажется, что она их ограничивает. Их тоже можно понять: они искренне недоумевают, почему кроме C# или Java, где они могут создать все что угодно, выполнить любые требования, им надо еще изучать эту систему. В результате после тотального кодирования в Low-Code платформе от нее остается лишь оболочка, все инструменты и преимущества цементируются в коде.

Заявленная скорость автоматизации и последующих изменений теряется. Поэтому не стоит удивляться, если для одного и того же действия, например, добавления кнопки на пользовательскую задачу, в одном проекте уйдет 40 человеко-часов, а в другом – 10 минут. При этом в обоих проектах используют одну и ту же BPMS.

Вместо перечисления других ошибок, которые я встречаю раз за разом в проектах, я объясню, как не допустить предыдущую ошибку. На самом деле, все очень просто. Если у вас сильная ИТ-команда, сложившаяся культура разработки, иными словами, вся тяжесть разработки как лежала на ИТ, так и будет лежать, – обратите внимание не на BPMS, а на BPM-движки. Данный класс ПО никак не ограничивает разработчиков, он лишь предоставляет инструмент по описанию процесса в графической нотации, а все остальное: база данных, пользовательские формы, интеграции и т.д., можно создать на любом языке программирования. Для этого требуется труд разработчиков и, соответственно, вся разработка так и остается на них. Если же вы принимаете решение использовать Low-Code, то вы должны помнить, для кого создавался этот инструмент, и дать вашим аналитикам там работать. При этом, особенно в крупных проектах, работы для классических разработчиков тоже будет достаточно. Например, создание сложных интеграций и веб-сервисов.

В чем и как можно измерить эффективность автоматизации процессов в банке?

Эффективность автоматизации, тем более в банках, нужно измерять в привычных для бизнеса деньгах. Конечно, исходными метриками могут быть скорость выдачи кредита, трудозатраты на конкретную операцию или FPY (first pass yield – показатель выхода первого раза – доля продукции, которая соответствует установленным требованиям на выходе производственной операции – прим. ред.). Но все эти метрики необходимо «перевернуть» в привычные бизнесу деньги.

Задать свои вопросы Георгию и узнать больше о Low-Code автоматизации вы сможете на Конференции «Оптимизация бизнес-процессов в банках», которая состоится 18 августа 2020 года.

Алиса Попова

Комментарии