Андрей Чепакин, ELMA: «Бизнес-процессы — это ключевое понятие, которое помогает бизнесу развиваться»

АНДРЕЙ ЧЕПАКИН: Совершенно верно. Очень отрадно, что российские компании наконец-то осознают возможности бизнес-процессов. На самом деле, бизнес-процессы — это ключевое понятие, которое помогает бизнесу развиваться. Многие наши заказчики спрашивают меня, зачем, собственно, заниматься бизнес-процессами? Почему мы должны при внедрении той или иной ИТ-системы всегда держать в голове, какие процессы мы меняем, и с какой целью их меняем? Я традиционно отвечаю следующим образом.

Если обратиться к методологии, то самое важное, наверное, это то, что формализованные, описанные и автоматизированные (то есть исполняемые) процессы создают почву для развития компании. Действительно, гораздо проще воплощать изменения, если есть понимание, ЧТО меняем и КАК меняем внутри компании.

Допустим, у нас есть бизнес-процесс обработки заказа или обработки рекламации. Он автоматизирован, формализован, и мы можем сравнивать его с лучшими практиками, понимать, что не устраивает клиента в текущем процессе. И мы понимаем, что конкретно надо менять: что в процессе можно ускорить, а что сделать более удобным для клиента. Поэтому формализация исполнения процессов – это почва для развития компании.Как DevOps-сервис помогает «разгрузить» высоконагруженные системы BPMSoft

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

Таким образом, когда компания задумывается над внедрением той или иной ИТ-системы - ERP, СЭД и т.д. – в процессном ракурсе – это совершенно верное действие. Потому что топ-менеджмент с помощью автоматизации может улучшить деятельность компании, а для этого нужно всегда понимать, какие бизнес-процессы мы будем улучшать. Вот почему многие ИТ-системы имеют на борту функционал работы с бизнес-процессами, что улучшает, скажем так, их практическую применимость.

АНДРЕЙ ЧЕПАКИН: Когда мы говорим об автоматизации сквозных процессов - роль BPM-системы возрастает многократно. BPM-система воплощает в себе процесс с самого его начала и до финального события. По сути, можно сказать, что BPM-система управляет процессом. При этом отдельные его участки могут быть реализованы во внешних ИТ-системах. Более того, определенные задачи процессов можно поручить RPA-роботам. Получается, что в процессе участвуют и сотрудники, работающие внутри BPM-системы, и роботы, и отдельные внешние ИТ- системы, а также сотрудники, работающие с внешними ИТ-системами. Таким образом, BPM-система становится «оркестратором» процессов и целиком воплощает весь процесс в себе.

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

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

АНДРЕЙ ЧЕПАКИН: Начиная проект внедрения BPM-системы, всегда необходимо понимать цель. Неправильно автоматизировать все процессы в целом. Я часто слышу от клиентов, что они хотели бы описать процессы. И тогда спрашиваю: а в чем цель? Что мы будем делать с этими описаниями? Похожая ситуация: «мы хотим внедрить BPM-систему, но еще не выбрали точку применения». Первое, что мы рекомендуем сделать, - это понять, что именно мы хотим изменить в работе компании, какой сквозной процесс или группа процессов для нас сейчас наиболее актуален. Какой процесс сейчас ограничивает рост компании и требует улучшения? Какой процесс необходимо развивать для достижения целевых показателей? Правильно рассматривать BPMS как инструмент, используя который можно изменить бизнес. Понятно, что этот инструмент нужно использовать грамотно, то есть четко и целенаправленно улучшая один процесс за другим. Поэтому ключевой первый этап – это определение цели внедрения BPM-системы. Скажем, по состоянию на сегодняшний день у нас есть определенные сложности в конкретной группе бизнес-процессов, и мы применяем инструмент BPM-систем с тем, чтобы устранить эти трудности – фактически расшить то «бутылочное горлышко», которое мешает росту компании.

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

АНДРЕЙ ЧЕПАКИН: BPM-система – гибкий продукт, и можно по-разному работать с бизнес-процессами в BPM-системе. Мы разработали свою шкалу из трех уровней изменений в бизнес-процессах организации.

Первый - Run (от слова «бежать»). Изменения на этом уровне позволят компании бежать быстрее. То есть компания будет делать тоже, что и всегда, но быстрее. На этом уровне мы не меняем логику бизнес-процессов, его схема остается прежней. Просто процесс будет автоматизирован в BPMS, и он начнет работать быстрее.

Следующий уровень - Change. Это более фундаментальный уровень изменений. В этом случае компания заранее планирует трансформировать процесс. Это значит, что мы не просто его автоматизируем, а используем BPMS для того, чтобы целенаправленно изменять бизнес-процесс, его метрики и показатели и таким образом формировать конкурентное преимущество. Это говорит о том, что выбранный процесс признан значимым для компании, и она планирует его развивать с помощью инструментария BPMS.

И третий уровень - Disrupt. В этом случае компания пытается перестроить свою бизнес-модель, то есть значительно изменить группу бизнес-процессов, возможно, создать совершенно новые бизнес-процессы, которые также войдут в пространство (scope) проекта внедрения BPM-системы.

АНДРЕЙ ЧЕПАКИН: Действительно, BPM-системы находятся ближе к Low-code, чем другие классы систем. Это не удивительно, так как визуальный редактор бизнес-процессов позволяет аналитикам без привлечения программистов выстраивать бизнес-логику работы системы. Бизнес видит, как можно быстро рисовать бизнес-процесс с помощью мышки, и полагает, что это и есть Low-code. На самом деле полноценная реализация Low-code только начинается с графического построения бизнес-процессов, но не заканчивается этим.

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

Например, в системе ELMA365 реализован графический конструктор объектов приложения: объект данных так же легко конструировать с помощью мышки. Так же настраиваем формы отображения этого объекта. По сути, этот инструментарий закрывает слой данных Low-code приложения.

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

Сочетание всех этих слоев и дает системе название «Low-code».

АНДРЕЙ ЧЕПАКИН: Отличный вопрос! Многие потенциальные клиенты сначала говорят именно об этом – о том, что с помощью Low-code инструментов ничего серьезного не сделать. На самом деле, это не так. Когда мы говорим Low-code BPM, например, ELMA365, то ориентируемся на две концепции: легкость входа и многослойность.

Легкость входа означает, что Low-code платформу можно начать использовать быстро. Достаточно пройти недельное обучение, и аналитик сможет создавать простые приложения.

Многослойность подразумевает, что при желании компания может углубляться в разработку. Причем, компания сама выбирает, какой уровень доработок или разработок на базе Low-code она будет использовать для создания корпоративного приложения. Таким образом, есть Low-code инструментарий для аналитиков – для быстрого создания приложений, и есть инструментарий для глубокой разработки. Получается, что на одной платформе можно создавать, как простые предложения, так и сложные. В результате, конечно, Low-code ускоряет создание корпоративных приложений. То, что в традиционной разработке делается месяцами, в Low-code можно сделать за недели.

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

АНДРЕЙ ЧЕПАКИН: Думаю, что для России эта цифра завышена. Хотя сейчас мы видим устойчивый запрос от бизнеса на самостоятельное создание корпоративных приложений силами отдельных департаментов. Топ-менеджмент понимает, что каким бы замечательным ни был их ИТ-департамент, где работают суперпрофессионалы, но все-таки именно ИТ может сдерживать развитие отдельных департаментов и бизнеса в целом. Топ-менеджмент хочет с помощью Low-code разрешить эту проблемную ситуацию и приходит с запросом на то, чтобы сами представители бизнес-департаментов создавали для себя корпоративные приложения и реализовывали проекты автоматизации в своих интересах, не дожидаясь ИТ-специалистов. В этом есть определенный здравый смысл.

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

АНДРЕЙ ЧЕПАКИН: Давайте для начала уточним содержание понятия «цифровая трансформация». Смысл цифровой трансформации заключается в изменении деятельности компании на уровне ее бизнес-модели. Это не значит, что мы просто автоматизируем тот или иной процесс, – это не цифровая трансформация, а, скорее, автоматизация (или цифровизация) того или иного процесса. В случае цифровой трансформации изменения несколько более фундаментальные. Как это происходит? Топ-менеджмент использует всевозможные схемы, которые описывают бизнес-модель компании. Например, можно взять популярную схему, предложенную Александром Остервальдером (Business Model Canvas). И на ее основе менеджмент принимает решение, в каком направлении следует менять компанию, и как должен измениться бизнес через пять лет? Будем ли мы по-прежнему продуктовой компанией или перейдем к сервисной и подписочной модели? Нужно ли нам по-прежнему держать логистику в своих руках или стоит перестроить бизнес-модель компании таким образом, чтобы внешние дистрибуторские или логистические компании включить в нашу цепочку создания ценности? Такого рода идеи фундаментальных изменений внутри самой бизнес-модели обдумывает топ-менеджмент, изучая соответствующие схемы. И затем задает вектор изменений бизнес-модели в ходе цифровой трансформации. А после этого следует обратить внимание на создание цифрового актива, это тот самый комплекс ИТ-систем, который воплотит в себе цифровую трансформацию и поможет достичь изменений бизнес-модели. Если мы ничего не меняем внутри компании, с точки зрения автоматизации, то вряд ли изменится и бизнес-модель.

Так вот, после того, как компания определилась с целью цифровой трансформации, мы начинаем определять для себя инструменты цифровой трансформации и создавать этот самый цифровой актив. Как я уже сказал, цифровой актив – это комплекс ИТ-систем. В него могут входить, как Low-code BPM-системы – для повышения гибкости бизнес-процессов, так и системы, предназначенные для обработки Big Data, - для получения аналитики, а также системы с искусственным интеллектом, если этого требуется для нашей цифровой трансформации.

Вы видите, что на первом месте – цель цифровой трансформации, а под нее уже подбирается цифровой актив. Фактически он конструируется компанией, и тогда внедрение той или иной ИТ-системы становится осознанным – понятно, для чего мы ее внедряем.

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

Допустим, у нас есть приложение для мобильного телефона, которое использует наш клиент. И теперь компания относится к этому приложению как к продукту, то есть появляется владелец продукта, бюджет продукта и процесс непрерывного развития этого продукта. Он подразумевает интервью с конечными клиентами и непрерывное улучшение продукта для того, чтобы максимизировать показатели экономики и т.д.

Этот пример иллюстрирует переход компании от проектной методологии к продуктовой модели. Он предполагает некие организационные изменения, о которых не следует забывать. Их-то и реализует команда по цифровой трансформации. Соответственно, эта команда работает и с цифровой зрелостью. Она приносит знания, методологии, учит конкретных бизнес-пользователей, меняя, в том числе, и корпоративную культуру компании.

АНДРЕЙ ЧЕПАКИН: Я считаю, что вектор развития Low-code будет направлен не в сторону упрощения создания корпоративных приложений. Я думаю, не приходится говорить о Now-code, ведь корпоративные приложения уже сегодня создаются относительно быстро и просто.

Инструментарий Low-code BPM должен развиваться в сторону клиентоориентированности. Это значит, что в этих системах уместно использовать искусственный интеллект – он будет влиять на работу самой системы, в зависимости от того, с каким клиентом Low-code взаимодействует.

Если мы говорим о клиентских процессах, которые реализованы внутри Low-code, то применение искусственного интеллекта сделает работу BPMS с каждым клиентом персонализированной – она будет уникальной для каждого клиента. Это первый важный момент – применение всевозможных способов встраивания искусственного интеллекта внутрь бизнес-процессов, которые автоматизированы в Low-code системе.

Также стоит говорить о развитии коммуникаций в сторону омниканальности. Я имею в виду использование интеллектуальных чат-ботов, которые могут прямо из бизнес-процесса коммуницировать либо с сотрудником компании, либо с внешним клиентом на понятном и приятном человеческом языке. На самом деле, это будет делать Low-code система, в которой реализован бизнес-процесс, включающий определенную задачу – коммуникацию с клиентом и инициирование этой коммуникации в удобном для клиента формате: позвонить в Teams голосом или написать в мессенджере.

АНДРЕЙ ЧЕПАКИН: Конечно! Сегодня мы уже умеем встраивать в ELMA 365 механизмы RPA. Это наша собственная реализация RPA, которая включает, в частности, роботов с искусственным интеллектом.

Также есть большое направление ELMA Сhat-desk, где мы работаем над многоканальностью, всевозможными коммуникациями: голосовыми, текстовыми. И мы умеем внутрь этого Chat-desk встраивать интеллектуального робота, построенного на базе нейронной сети. Этот робот, который тоже разработан в нашей компании, умеет вести диалог в «человеческой» манере. В этом направлении мы активно движемся вперед.