Svetlana_J
New member
Работаю в ИТ уже больше десяти лет и за последние три года через меня прошло, наверное, два десятка проектов на low-code и no-code платформах. Скажу честно: я долго относился к этому направлению свысока. Мне казалось, что конструктор вместо кода — это игрушка для отдела маркетинга, которая развалится при первом же серьёзном сценарии. Первый же нормальный заказ заставил меня поменять мнение, а второй и третий — понять, где именно проходит граница между экономией и разрушением бизнес-процесса.
Там, где автоматизация реально экономит, всё обычно выглядит скромно и неинтересно. Это сбор заявок, согласование отпусков, уведомления, простые отчёты, интеграция двух сервисов через вебхук, внутренняя база знаний. Мой любимый пример: у небольшой логистической компании менеджеры вручную переносили заявки от клиентов в таблицу, теряли по пять-семь обращений в неделю и не могли ответить, кто на каком этапе. Мы собрали на no-code платформе форму приёма заявок, автоматическую маршрутизацию по менеджерам и напоминания. Три недели работы одного человека вместо трёх месяцев разработки, стоимость — примерно в пять раз ниже, чем у заказной системы. Окупилось за два с половиной месяца, и это чистая экономия без всяких оговорок.
Экономия проявляется ещё в одном сценарии, который многие недооценивают: прототип. Когда бизнес не может внятно сформулировать требования, гораздо эффективнее за неделю накидать работающий макет на конструкторе, показать его людям и собрать обратную связь, чем полгода писать техническое задание. Потом этот прототип либо выбрасывается, либо аккуратно переезжает в нормальный код. Стоимость ошибки на этом этапе почти нулевая, а именно ошибки в требованиях съедают основные бюджеты в разработке.
А теперь про то, где всё ломается. Первый тревожный признак — процесс, который в реальности живёт не по правилам, а по исключениям. Если у вас в заявке двенадцать условий согласования, три уровня эскалации и логика вида «если сумма больше, но поставщик из списка, то...», конструктор начинает трещать. Бизнес просит доработку, вы добавляете ещё одно условие, потом ещё одно, и через полгода никто, включая автора, не может объяснить, почему заявка ушла не тому руководителю. Мы как-то разбирали такой случай: согласование платежей в компании превратилось в чёрный ящик, а когда платформа обновила версию визуального редактора, часть логики просто перестала работать. Никто не смог быстро понять, что именно сломалось.
Второй источник проблем — теневые процессы и потеря контроля. Low-code отлично снижает порог входа, но вместе с ним снижает и порог ответственности. Начинается всё с безобидного: бухгалтерия сама собирает себе мини-приложение, отдел продаж заводит свою автоматизацию, логисты — свою. Через год у компании пять баз данных с клиентами, три версии справочника товаров и никакой единой картины. Ни ревью, ни тестов, ни документации, ни владельца. Уходит сотрудник, который всё это собирал, и вместе с ним уходит знание о том, как устроен процесс. Это уже не экономия, это технический долг, который однажды придётся гасить деньгами и нервами.
Отдельно скажу про критичные процессы. Всё, что связано с деньгами, персональными данными, юридически значимыми операциями и высокой нагрузкой, я бы в конструктор не отдавал. Не потому, что платформы плохие, а потому, что там нужны аудит, контроль доступа, тестирование, версионирование и понятный путь миграции. Если система падает и останавливает продажи или выплаты, вы не отделаетесь письмом в поддержку и обещанием починить в следующем релизе. Плюс почти всегда есть риск привязки к вендору: цены меняются, тарифы пересматриваются, а вытащить свою логику и данные из некоторых платформ — это отдельный проект.
Так как же решать? Я для себя вывел довольно простой набор вопросов. Процесс стабильный и повторяемый или меняется каждые две недели? Сколько в нём исключений — два или двадцать? Насколько он критичен для выручки? Как глубоко он должен быть связан с другими системами? Кто будет владельцем решения и что будет, если этот человек уйдёт? Если процесс простой, стабильный и не критичный — берите low-code смело, сэкономите время и деньги. Если он сложный или критичный — берите, но как прототип, и сразу планируйте переезд в код с нормальной архитектурой.
Читателям форума дам практические советы. Начинайте с одного небольшого процесса и обязательно измеряйте результат в часах и деньгах, иначе спор превратится в вопрос веры. Заведите правило: любое решение, которое живёт больше трёх месяцев, должно иметь владельца, описание и выгружаемые данные. Не давайте бизнес-подразделениям собирать интеграции с деньгами и персональными данными без участия ИТ. И держите в голове план выхода — как вы переедете, если платформа подорожает или закроется. Low-code и no-code — это отличный инструмент, но инструмент, а не религия. Он экономит там, где вы понимаете свой процесс, и ломает там, где вы надеетесь, что конструктор поймёт его вместо вас.
А теперь вопрос к вам, коллеги: какие процессы вы уже перевели на low-code или no-code и что из этого получилось — ускорились, сэкономили или наоборот собрали себе проблемы на будущее? Поделитесь историями, особенно удачными, — вместе мы точно составим более честную карту того, где стоит нажимать на кнопку, а где лучше не рисковать.
Там, где автоматизация реально экономит, всё обычно выглядит скромно и неинтересно. Это сбор заявок, согласование отпусков, уведомления, простые отчёты, интеграция двух сервисов через вебхук, внутренняя база знаний. Мой любимый пример: у небольшой логистической компании менеджеры вручную переносили заявки от клиентов в таблицу, теряли по пять-семь обращений в неделю и не могли ответить, кто на каком этапе. Мы собрали на no-code платформе форму приёма заявок, автоматическую маршрутизацию по менеджерам и напоминания. Три недели работы одного человека вместо трёх месяцев разработки, стоимость — примерно в пять раз ниже, чем у заказной системы. Окупилось за два с половиной месяца, и это чистая экономия без всяких оговорок.
Экономия проявляется ещё в одном сценарии, который многие недооценивают: прототип. Когда бизнес не может внятно сформулировать требования, гораздо эффективнее за неделю накидать работающий макет на конструкторе, показать его людям и собрать обратную связь, чем полгода писать техническое задание. Потом этот прототип либо выбрасывается, либо аккуратно переезжает в нормальный код. Стоимость ошибки на этом этапе почти нулевая, а именно ошибки в требованиях съедают основные бюджеты в разработке.
А теперь про то, где всё ломается. Первый тревожный признак — процесс, который в реальности живёт не по правилам, а по исключениям. Если у вас в заявке двенадцать условий согласования, три уровня эскалации и логика вида «если сумма больше, но поставщик из списка, то...», конструктор начинает трещать. Бизнес просит доработку, вы добавляете ещё одно условие, потом ещё одно, и через полгода никто, включая автора, не может объяснить, почему заявка ушла не тому руководителю. Мы как-то разбирали такой случай: согласование платежей в компании превратилось в чёрный ящик, а когда платформа обновила версию визуального редактора, часть логики просто перестала работать. Никто не смог быстро понять, что именно сломалось.
Второй источник проблем — теневые процессы и потеря контроля. Low-code отлично снижает порог входа, но вместе с ним снижает и порог ответственности. Начинается всё с безобидного: бухгалтерия сама собирает себе мини-приложение, отдел продаж заводит свою автоматизацию, логисты — свою. Через год у компании пять баз данных с клиентами, три версии справочника товаров и никакой единой картины. Ни ревью, ни тестов, ни документации, ни владельца. Уходит сотрудник, который всё это собирал, и вместе с ним уходит знание о том, как устроен процесс. Это уже не экономия, это технический долг, который однажды придётся гасить деньгами и нервами.
Отдельно скажу про критичные процессы. Всё, что связано с деньгами, персональными данными, юридически значимыми операциями и высокой нагрузкой, я бы в конструктор не отдавал. Не потому, что платформы плохие, а потому, что там нужны аудит, контроль доступа, тестирование, версионирование и понятный путь миграции. Если система падает и останавливает продажи или выплаты, вы не отделаетесь письмом в поддержку и обещанием починить в следующем релизе. Плюс почти всегда есть риск привязки к вендору: цены меняются, тарифы пересматриваются, а вытащить свою логику и данные из некоторых платформ — это отдельный проект.
Так как же решать? Я для себя вывел довольно простой набор вопросов. Процесс стабильный и повторяемый или меняется каждые две недели? Сколько в нём исключений — два или двадцать? Насколько он критичен для выручки? Как глубоко он должен быть связан с другими системами? Кто будет владельцем решения и что будет, если этот человек уйдёт? Если процесс простой, стабильный и не критичный — берите low-code смело, сэкономите время и деньги. Если он сложный или критичный — берите, но как прототип, и сразу планируйте переезд в код с нормальной архитектурой.
Читателям форума дам практические советы. Начинайте с одного небольшого процесса и обязательно измеряйте результат в часах и деньгах, иначе спор превратится в вопрос веры. Заведите правило: любое решение, которое живёт больше трёх месяцев, должно иметь владельца, описание и выгружаемые данные. Не давайте бизнес-подразделениям собирать интеграции с деньгами и персональными данными без участия ИТ. И держите в голове план выхода — как вы переедете, если платформа подорожает или закроется. Low-code и no-code — это отличный инструмент, но инструмент, а не религия. Он экономит там, где вы понимаете свой процесс, и ломает там, где вы надеетесь, что конструктор поймёт его вместо вас.
А теперь вопрос к вам, коллеги: какие процессы вы уже перевели на low-code или no-code и что из этого получилось — ускорились, сэкономили или наоборот собрали себе проблемы на будущее? Поделитесь историями, особенно удачными, — вместе мы точно составим более честную карту того, где стоит нажимать на кнопку, а где лучше не рисковать.