ProcessMasster - системы, логика, no-code

Последние недели у нас были не про красивые новые кнопки.

Мы закрывали один из самых важных этапов для TugunX - production hardening.

Прошлись по очередям и выполнению сценариев, ограничениям ресурсов, работе с credentials, исходящим HTTP-запросам, восстановлению паролей, изоляции Function-node, резервному копированию базы, зависимостям и уязвимостям.

Самое главное - всё это уже не просто код в репозитории. Обновление выкатили на production и прогнали реальные сценарии. Всё работает штатно.

Для пользователя результат выглядит просто: TugunX стал устойчивее к ошибкам, безопаснее в работе с данными и секретами и лучше подготовлен к росту нагрузки.

Этот этап можно официально закрывать:

TugunX Production Hardening P0 - done ✅

А теперь возвращаемся к тому, что будет заметнее снаружи - развитию продукта и пользовательского опыта.

На выходных немного откатился назад.

Не в коде 🙂 А в истории TugunX.

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

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

Некоторые идеи мы выбросили. Некоторые переделывали несколько раз. А какие-то решения, принятые ещё в самом начале, до сих пор остаются фундаментом проекта.

В итоге решил собрать весь этот путь в одну картину.

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

Скоро покажу.

Несколько недель назад AI Builder существовал только у нас в голове.

Сегодня это уже рабочая часть TugunX.

В этом видео показываю текущий прогресс.

Сейчас AI Builder уже умеет:
• анализировать описание процесса обычным языком;
• постепенно формировать понимание процесса;
• задавать уточняющие вопросы там, где действительно не хватает информации;
• показывать своё понимание процесса ещё до построения автоматизации;
• после подтверждения генерировать первый черновик Flow.

До финальной версии ещё далеко.

Мы продолжаем улучшать качество вопросов, глубину понимания процессов и логику построения автоматизации. Но самое сложное уже позади - AI перестал просто искать ключевые слова и начал работать с логикой процесса.

Будем постепенно делиться новыми этапами разработки.

Интересно будет услышать ваше мнение. Что бы вы добавили или изменили?

Я много писал о том, каким должен стать AI Builder в TugunX.

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

На скриншоте результат одного из последних тестов.

Процесс согласования командировок был разобран, структурирован и превращён в полноценный Flow с ветвлениями, проверками, статусами и уведомлениями.

Это ещё не финальная версия. Но уже не просто концепция.

Это работает.

В течении часа покажу весь путь, от первого описания процесса до готовой схемы.

Пока все обсуждают AI-агентов, мы решаем другую проблему.

Я заметил интересную вещь во время разработки AI Builder.

Оказалось, что заставить AI нарисовать красивую схему процесса - относительно просто.

Гораздо сложнее научить его задавать правильные вопросы.

Настоящий бизнес-аналитик не задаёт двадцать вопросов подряд:

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

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

Именно этому мы сейчас учим AI в TugunX.

По сути, мы создаём не генератор диаграмм. Мы создаём цифрового бизнес-аналитика.

Такого, который сначала слушает.

Потом уточняет только действительно важные детали.

Показывает, как понял процесс. Получает подтверждение.

И только после этого проектирует автоматизацию.

Чем больше мы работаем над этим, тем сильнее убеждаемся:

Будущее автоматизации - это не AI, который умеет рисовать Flow.

Будущее - это AI, который умеет понимать бизнес.

В предыдущем посте я писал, что автоматизация начинается не с выбора CRM, ERP или AI.

Сначала нужно понять сам процесс.

Но здесь возникает следующий вопрос:

А что будет, если человеку больше не придётся самостоятельно собирать автоматизацию по шагам?

Сегодня большинство платформ работают одинаково.

Пользователь уже должен знать:
- с чего начинается процесс;
- какие действия нужно выполнить;
- где поставить условие;
- как соединить системы;
- что делать при ошибке.

После этого он открывает редактор и начинает вручную собирать цепочку из узлов.

По сути, чтобы автоматизировать процесс, человек сначала должен сам стать аналитиком, архитектором и техническим специалистом.

Мне кажется, этот подход постепенно будет меняться.

Вместо того чтобы вручную объяснять системе каждый технический шаг, пользователь сможет описать задачу обычным языком:

- Нужно согласовывать командировки сотрудников.
- Проверять заполнение заявки, передавать её руководителю, затем проверять бюджет и возвращать сотруднику причину отказа.

Но AI не должен сразу рисовать красивую схему.

Сначала он должен понять:
- зачем существует процесс;
- кто в нём участвует;
- где принимаются решения;
- какие правила влияют на маршрут;
- что происходит в нестандартных ситуациях;
- каким результатом процесс должен завершиться.

Если информации недостаточно -задать несколько точных вопросов.

Затем показать пользователю, как процесс был понят.

И только после подтверждения предложить логику и техническую реализацию.

Именно над таким подходом мы сейчас работаем в TugunX.

Не над генератором случайных цепочек по одному запросу.

А над AI, который сначала разбирается в процессе и только потом помогает его автоматизировать.

На мой взгляд, будущее автоматизации выглядит не так:

❌Человек строит Flow.

А так:

✅Человек описывает цель.
✅AI помогает понять процесс.
✅Платформа строит реализацию.

Именно к этому мы хотим прийти в TugunX.

Очень много думаю о том, куда вообще движется рынок автоматизации.

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

Сейчас всё чаще появляются AI-first платформы, где достаточно описать задачу обычным языком, а AI сам предлагает первый вариант рабочего процесса.

И, честно говоря, мне кажется, что это абсолютно закономерное развитие рынка.

Но чем больше мы обсуждаем это внутри команды TugunX, тем чаще возвращаемся к другому вопросу.

Если AI научится строить рабочие процессы, то что останется человеку?

Именно здесь, как мне кажется, начинается самое интересное. Возможно, настоящая ценность уже не в том, чтобы соединить между собой Telegram, CRM, AI и ещё десяток сервисов.

Настоящая ценность в понимании самого бизнес-процесса.
- Зачем он существует?
- Какую задачу решает?
- Где в нём узкие места?
- Что действительно стоит автоматизировать, а что лучше оставить человеку?

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

Сейчас мы как раз переосмысливаем эту идею внутри TugunX. Не потому, что хотим сделать ещё один AI-конструктор, а потому что пытаемся понять, какой должна быть платформа через 3-5 лет, когда AI станет привычным рабочим инструментом.

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

💬 Интересно узнать ваше мнение.

Как вы думаете, через несколько лет люди всё ещё будут вручную собирать автоматизации в визуальных редакторах, или большинство процессов будет создаваться и настраиваться с помощью AI, а визуальный редактор останется инструментом для более сложных сценариев и опытных специалистов?

За последнее время разработки TugunX я понял одну неприятную вещь.

Практически каждый разговор об автоматизации начинается одинаково.
- Нам нужна CRM.
- Нужно внедрить ERP.
- Давайте подключим AI.
- Может, перейти на другую систему?

И почти никогда не начинается с вопроса: А как вообще сейчас работает наш процесс?

За последние несколько лет мне довелось работать с разными системами: SAP, Bitrix24, Excel, Telegram, корпоративными сервисами и собственными решениями.

И знаете, что оказалось самым неожиданным? Проблема почти никогда не была в самих инструментах.

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

Из-за этого компании меняют одну систему на другую, подключают новые сервисы, внедряют AI, но спустя время снова сталкиваются с теми же проблемами.

Мы тоже начинали TugunX как платформу автоматизации. Но чем глубже погружались в разработку и общались с компаниями, тем сильнее менялось наше понимание.

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

И только после этого выбирать инструменты, внедрять AI и строить автоматизацию.

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

И слишком мало обсуждаем процессы.

Именно вокруг этой идеи теперь будет развиваться TugunX.

Теперь разбирать прогоны стало в разы проще

Мы сильно прокачали execution-страницу и аналитику прогонов.

Что изменили:
- сделали правую панель заметно удобнее для разбора
- добавили переключение по нодам прямо из схемы
- теперь при клике показываются данные именно выбранной ноды
- вынесли Input / Output / Meta в понятный формат для анализа
- убрали лишний шум и дублирование
- улучшили читабельность и компоновку, чтобы быстрее находить проблему в прогоне

Что это дает:
- меньше времени на ручной разбор
- быстрее видно, где flow ведет себя не так
- проще сравнивать вход, выход и метаданные
- удобнее искать узкие места и аномалии в логике

Итог:
execution-страница стала не просто экраном с результатом прогона, а нормальным инструментом для диагностики.

Хочу немного свериться с вами по развитию TugunX 👀

Сейчас постепенно выходим на этап активного расширения интеграций внутри платформы.

И здесь хочется идти не куда все идут, а туда, где это реально нужно в работе.

Поэтому интересно узнать, какие 5 интеграций для вас были бы самыми полезными?

Это может быть что угодно. Можно просто списком в комментариях.

Будет очень полезно для определения следующих направлений развития платформы 👌

Долго думал над тем, какая фича могла бы по-настоящему отличать TugunX от других сервисов автоматизации в части работы с данными и expressions.

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

- Где-то это выглядит как набор функций.
- Где-то как JavaScript expressions.
- Где-то как отдельные formatter-ноды.

Но в реальных сценариях проблема обычно не в том, что нет функции.

Проблема в другом: пользователь не всегда понимает, что именно пришло в ноду, как это значение достать, что с ним происходит после преобразования и почему на выходе получилось именно так.

Поэтому последние дни мы плотно дорабатывали в TugunX ноду Transform Data.

Идея была простая: не заставлять пользователя думать функциями, а дать ему понятный способ работать с данными.

Например, Bitrix24 может отправить ID сделки вот так: DEAL_10100

А дальше для HTTP-запроса нужен только номер: 10100

Или webhook может прислать массив:
document_id = ["crm", "CCrmDocumentDeal", "DEAL_10100"]

А нам нужно взять третий элемент, убрать DEAL_ и превратить результат в число.

Теперь это можно собрать в Transform Data пошагово:
- взять document_id
- взять 3-й элемент
- убрать DEAL_
- конвертировать в число

Без сложной формулы и без лишних костылей.

Что добавили:

1. Transform value mode - Для обработки одного значения: очистить текст, заменить текст, достать элемент массива, получить поле из объекта, преобразовать в число, работать со списками и датами.

2. Calculate mode - Для расчётов между несколькими значениями.

Например: var2 - var1 = result

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

3. Calculation templates - Добавили готовые шаблоны для частых бизнес-расчётов:
- Difference: A - B
- Sum: A + B
- Price × Quantity
- Percentage of target
- Percentage difference

Пользователь выбирает шаблон, подставляет свои значения и сразу видит результат.

4. Preview с объяснением - Это, наверное, самая важная часть.

Теперь можно видеть не просто итог, а то, как он получился:

Start with
var2 = 1598

Subtract
var1 = 1000

Result
598

Если значение не найдено или не является числом - это тоже видно сразу.

5. Более чистый просмотр данных - Мы убрали визуальный шум из input/output. Headers, raw, webhook metadata и прочие технические данные теперь не мешают в основном просмотре. При этом debug-данные остаются доступны отдельно.

Для меня это важное обновление.

Потому что автоматизация это не только соединить Bitrix24, Telegram, HTTP, Google Sheets и другие сервисы.

Очень часто настоящая работа происходит между этими шагами:

- достать нужное значение,
- очистить его,
- преобразовать,
- посчитать,
- передать дальше в правильном виде.

Именно здесь обычно начинается сложность.

Мы хотим, чтобы в TugunX работа с данными была не спрятана в непонятные expressions, а была видимой, пошаговой и объяснимой.

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

Уххх...

Сегодня будет длинный пост про очередное большое обновление TugunX.

На этот раз не про новую интеграцию и не про красивую кнопку. А про то, без чего нормальная автоматизация почти всегда разваливается - работу с данными.

Expressions, преобразования, массивы, расчёты, preview результата и всё то, что обычно прячется где-то под капотом.

Мы долго думали, как сделать этот слой понятнее и удобнее. Кажется, получилось очень важное обновление.

Через часик расскажу подробнее... 🔥

На скрине один из сценариев в TugunX:

новое событие в Google Calendar -> сохраняется в таблицу -> проходит через обработку -> и дальше используется для отправки email

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

Именно в этом для меня смысл всей платформы.

Не просто соединить инструменты, а собрать процесс так, чтобы он был понятен, управляем и предсказуем.

Пока логика живёт в голове, чатах и ручных действиях всегда будет хаос и зависимость от человеческого фактора.

Когда эта логика превращается в сценарий процесс становится совсем другим.

Такие сценарии уже можно собирать в TugunX. Постепенно будем открывать всё больше возможностей.

Выкатил в MVP одну из ключевых фич - внутренние таблицы.

Теперь внутри сценариев появилась полноценная работа с данными:
- получать записи
- фильтровать
- проверять условия
- создавать новые строки
- использовать данные дальше в логике

На скрине пример простого сценария:
- Приходит запрос через Webhook
- Получаем данные из таблицы
- Проверяем условия через фильтр
- Если запись есть, одно действие
- Если нет, создаём новую и выполняем другое действие

По сути, сценарии становятся не просто цепочкой действий, а системой, которая умеет принимать решения на основе данных.

Это открывает нормальные практические кейсы:
- учёт заявок
- проверка существующих записей
- логика “если есть / если нет”
- накопление данных внутри процессов

Фича уже доступна в MVP - можно тестировать.

Сценарий на скрине - один из базовых примеров. Дальше можно строить гораздо более сложные вещи.

Постепенно закрываю ещё один важный слой внутри платформы - внутренние таблицы.

По сути это возможность хранить и использовать данные прямо внутри потоков, без привязки к внешним сервисам.

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

Раньше для таких задач приходилось подключать сторонние сервисы. Теперь это можно делать внутри одной среды.

Это сильно упрощает сценарии. И делает их более стабильными.

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

Скоро выкачу в MVP.

Если есть идеи, как бы вы использовали таблицы внутри сценариев - напишите. Интересно посмотреть на реальные кейсы.

Собрал ещё один живой сценарий - AI-дайджест новостей из RSS.

По сути это улучшенный сценарий из поста выше.

Что делает поток:
- забирает новости из нескольких RSS-источников,
- объединяет и чистит данные,
- прогоняет каждую новость через AI (краткое резюме + ключевая мысль + хэштеги),
- собирает всё обратно в один массив,
- формирует HTML-дайджест и отправляет в Telegram.

Цепочка нод:

RSS - Merge - Function - Iterator - GPT - Function - Array Aggregator - Function - Telegram

Зачем тут Iterator + Array Aggregator:

Iterator даёт обработать каждую новость отдельно (AI работает по item’ам, а не по всей куче сразу)

Array Aggregator собирает результаты обратно, чтобы дальше можно было красиво собрать один пост/дайджест

Итог: полностью автоматизированный контент-пайплайн - от источников до готовой публикации в Telegram, без ручной рутины.

Какую интеграцию вы бы хотели увидеть следующей? Напишите название сервиса - соберём очередь.

В любой автоматизации есть один важный элемент - логика принятия решений.

Нода Switch.

Она проверяет значение переменной и направляет сценарий в нужную ветку. В зависимости от входящих данных поток может продолжить работу по разным сценариям.

Как это выглядит на практике:
- В систему приходит запрос через Webhook
- Нода Set Variable сохраняет значение
- Switch проверяет это значение
- Сценарий отправляется в нужную ветку

В каждой ветке можно настроить своё действие. На примере на скриншоте это отправка сообщения в Telegram.

Такая логика позволяет одному сценарию обрабатывать разные события:
- разные типы запросов
- разные статусы
- разные пользователи
- разные источники данных

Фактически Switch управляет поведением всего потока.

Без этой ноды любой сценарий превращается в линейную цепочку действий.

С ней, в полноценную систему автоматизации, которая умеет реагировать на входящие данные и выполнять нужные действия.