От low-code анархии и легаси-диктатуры к управляемой процессной демократии

Low-code – это не новость и не тренд, сегодня каждая вторая (если не первая) платформа дает возможности для low-code настройки. Почему это не всегда во благо, разбираемся с исполнительным директором ELMA Наталией Долженковой.

Этапы становления

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

Кейс: «кнопка для бухгалтерии» в эпоху диктатуры IT

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

Путь к ней выглядел так:

1. Заявка. Бухгалтерия пишет служебную записку в IT-отдел с просьбой «сделать кнопку, которая будет формировать отчет».
2. Аналитика (1-2 месяца). IT-аналитик проводит серию встреч с бухгалтерией, чтобы составить формальное техническое задание (ТЗ) на 30 страниц, где описывается каждый столбец, каждая формула и источник данных.
3. Оценка и планирование (1 месяц). Руководитель разработки оценивает ТЗ, понимает, что это затронет ядро системы, и ставит задачу в план релиза через полгода, так как текущий релиз уже заморожен.
4. Разработка и тестирование (2 месяца). Программисты пишут код, тестировщики проверяют его на тестовом стенде.
5. Внедрение. В таком режиме выйти на этот этап можно спустя 9-10 месяцев. Во время ночного технологического окна обновление «выкатывают» на основной сервер.

И вот момент счастья – у пользователя в руках долгожданная кнопка. Только вот выглядит она не совсем так, как хотелось бы. А переделка – это что? Все по новой.

Что в этой ситуации хорошо – ответственность бизнеса за создание и обеспечение работой сотрудников на местах. Как говорится, фабрики рабочим, а кодинг – программистам. Если чуть серьезнее, то при таком подходе бизнес:

• не платит никому, кроме своих же разработчиков или тех, кто условно у них в найме;
• получает ровно то, что описывает – не больше, но и не меньше.

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

И тут кто-то предприимчивый придумал концепцию быстрого прототипирования. Если углубиться в историю – на самом деле никакого одинокого героя-изобретателя не было: первые мины под IT-диктатуру заложили еще в 90-х с помощью инструментов быстрой разработки (RAD), позволивших собирать программы из готовых кубиков. А модный ярлык «low-code» всей этой партизанщине приклеили уже в 2014-м аналитики из Forrester, просто дав официальное название давно начавшейся анархии.

Кейс: «оптимизация» отдела продаж в эпоху анархии

Торговая компания внедряет новую CRM с мощным low-code-конструктором. Руководитель отдела продаж, человек деятельный и вдохновленный, решает «подкрутить» систему под себя без привлечения IT.

Что происходит за месяц:

• Карточка клиента. В карточку клиента с помощью drag-and-drop добавляется 40 новых полей: «Знак зодиака», «Любимый напиток», «День рождения кота», «Настроение на последнем звонке» и т.д. Большинство из них не обязательны к заполнению и не используются.
• Бизнес-процессы. Настраивается 15 параллельных бизнес-процессов. Один отправляет клиенту SMS, если ему не звонили 3 дня. Другой ставит задачу менеджеру, если тот не заполнил поле «Настроение». Третий автоматически меняет статус сделки, если клиент открыл письмо.
• Результат. Система начинает тормозить из-за перегруженной карточки. Процессы конфликтуют друг с другом: клиенты получают по 5 разных уведомлений в день. Новые менеджеры не могут понять, какие из 40 полей действительно нужно заполнять. Данные для аналитики собрать невозможно, так как они хаотичны и неполны.

И вот вроде по-другому, но теперь не нравится уже тем самым айтишникам – потому что оно все изменяется быстро и местами даже работает, но вот поддерживать такую систему сложно. Раньше, пусть долго, пусть с препираниями, но родненький айтишник выполнял все что скажешь и как скажешь, а тут эта шайтан-машина лоукодная ограничения имеет. И вот уже бизнес кошмарят не люди, а их собственноручно созданный «Франкенштейн».

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

В общем, опять не идеально.

Эволюция инструментов

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

Пример «волка в овечьей шкуре»

Компания покупает платформу для автоматизации бизнес-процессов. В рекламных материалах показан красивый визуальный редактор, где можно мышкой рисовать схемы процессов. Маркетологи и аналитики в восторге. Они рисуют идеальный процесс согласования договора. Но когда доходит до дела – например, до шага «Отправить данные из договора в 1С» – оказывается, что стандартного блока для этого нет. Кнопка «Настроить интеграцию» ведет на форму «Оставьте заявку, и наш специалист свяжется с вами для оценки стоимости работ по интеграции». В итоге каждый шаг, выходящий за рамки «отправить email» или «поставить задачу», требует дорогостоящей доработки силами вендора.

Что плохого? Да в целом-то ничего, только цифры в ТСО (Total Cost of Ownership – общая стоимость владения) будут заоблачными.

Управляемый болид или как выбрать low-code

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

Ролевая модель: кесарю кесарево, слесарю слесарево

Ролевая модель – это не просто «админ/пользователь». Зрелая ролевая модель – это гибкая система разграничения прав не только на доступ к данным, но и на возможность вносить изменения. В идеальной системе вы можете создать роли с разными уровнями «творческой свободы»:

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

Ключевая возможность – «Песочница» (Sandbox). У аналитика есть своя тестовая копия процесса. Он может вносить любые изменения, тестировать их, и только после того, как все заработает, он нажимает кнопку «Отправить на согласование в IT». IT-специалист проверяет, что изменения не нарушают общую архитектуру, и одной кнопкой «публикует» их для всех сотрудников. Это и есть демократия под контролем.

Уровень настройки платформы: сколько слоев у пирога

Обращаем внимание, какие именно элементы подлежат конфигурированию: объекты, поля, процессы или всё вместе? Необходимо понять, способен ли обычный сотрудник разобраться самостоятельно, не обладая специальными знаниями, и что произойдет, если встроенных инструментов окажется недостаточно.

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

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

• No-code (для бизнес-пользователей) – украшение на торте, то, что бросается в глаза первым делом и доступно и нравится всем. Если конкретнее – это набор визуальных конструкторов, где не нужно писать ни строчки кода. Пример: руководитель отдела кадров сам, мышкой, добавляет в процесс найма новый этап «Проверка службой безопасности» и ставит галочку «Обязательный». Или в карточке контрагента появилось новое поле “LTV”, которое считается как сумма всех выставленных актов – для этого коммерческий директор может зайти в карточку, добавить поле и ввести к нему простую формулу.
• Low-code – начинка. В этом слое часто вся суть. С его помощью можно настроить те уникальные правила, процессы или формы, которые отличают ваши паттерны работы от работы других подобных компаний на рынке – и они же помогают вам выигрывать. Настройкой low-code уже занимаются аналитики и «продвинутые» пользователи. Здесь появляются и более сложные формулы в стиле Excel, простые скрипты или визуальное моделирование (BPMN) для описания сложной логики. Например, финансовый аналитик настраивает правило: «Если сумма в счете больше 1 млн рублей и контрагент новый, то процесс согласования должен пойти по ветке с участием финансового директора». Или же аналитик настраивает более сложную цепочку того, в какой последовательности должны проходить этапы выпуска продукции на производстве, начиная от закупок и заканчивая поставкой и логистикой, учитывая настройку прав доступа к нужной на данном этапе информации, ролевую модель и условия выполнения задач.
• Code (для разработчиков) – классический бисквит этого слоеного шедевра. Сразу стоит оговориться: он бывает не всегда. Существует ряд задач, решаемых low-code и no-code платформами, которые не требуют введения тяжелой артиллерии. Но если нужно реализовать сложную интеграцию с легаси или написать новый уникальный сервис, то тут этот слой ложится как прочный фундамент. Что в нем? Полноценный доступ к API и SDK платформы. Если для интеграции с унаследованной складской системой нужен сложный код на Python или C#, разработчик может написать этот модуль, «упаковать» его в виде простого блока и отдать аналитикам для использования в low-code-слое.

Таким образом, «диктатура IT» превращается в создание удобных инструментов для бизнеса.

Дополнительный, но критически важный аспект – так сказать, вишенка на торте – управление версиями и легкий откат. Любое изменение, внесенное в процесс (даже на уровне no-code), должно сохраняться как новая версия. Если после «оптимизации» от руководителя отдела продаж все сломалось, IT-специалист должен иметь возможность зайти в систему, увидеть историю изменений и одной кнопкой откатить процесс к вчерашней стабильной версии. Это страховка от анархии. А для сложных и разветвленных конфигураций вендора все чаще реализуют инструменты доставки изменений с помощью CI/CD.

Управляемая IT-демократия: резюме

Зрелый подход к low-code в корпоративной среде кардинально смещает фокус с вопроса «как быстро мы можем что-то создать?» на вопрос «как мы можем создавать быстро, но при этом выстраивать управляемый и долговечный цифровой актив?». Ответ на него лежит в плоскости синергии: организационные изменения (вроде создания центра компетенций) должны опираться на правильный технологический фундамент. Стратегия без инструментального воплощения – лишь декларация о намерениях. А россыпь пусть даже мощных инструментов без единой стратегии – прямой путь к «лоскутной» автоматизации и технологическому хаосу, от которого все так стремятся убежать.

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

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

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