9 признаков, что пора уходить с Excel на no-code

Все любят таблицы. Даже те, кто делает инновационные приложения с базами данных (те же Airtable, Glide и прочие), равняются на Excel. Однако, если вы отлично владеете этим инструментом, но перенасытили его хаотичными данными, будет не только много пользы, но и вред. Как понять, что пора переходить с Excel на конструкторы? Вот несколько признаков:

1. Нет ролей и прав: любой правит всё, а это приводит к потерям данных и конфликтам версий
2. ‍Ошибки в формулах и дубли: отчёты начинают «плясать», приходят возмущенные сотрудники и клиенты, доверие падает
3. ‍Тормоза на объёмах: файл становится все больше, при этом полезных фильтров не так много, а нужных сведений никак не найти
4. ‍Аудит? Не, не слышали: неясно, кто что изменил и когда
5. ‍Согласования по почте/чату: задачи актуализируются где угодно, кроме самих таблиц - в результате, статусы почти всегда отстают, задачи теряются, отслеживать дедлайны почти невозможно
6. ‍Ручные интеграции: CRM/ЭДО/почта синхронизируются «копипастом»
7. ‍Команда растёт, при этом все ходят в таблицы и вносят туда что-то свое - одновременная работа ломает файлы
8. ‍Ручные отчёты: много сводок = много ошибок и часов
9. ‍Риски ПДн/безопасности: файлы гуляют по дискам и мессенджерам
   

Поставили больше 5 плюсиков? Диагноз ясен: вам пора искать альтернативу Excel. Для небольшого бизнеса без программистов это no-code.

План миграции на no-code за 10 дней

Легко сказать, но сложно сделать? Здесь мы предлагаем простой пошаговый план миграции с Excel на конструкторы без кода.

День 1–2 — Аудит (что есть сейчас)

Цель: понять, какие данные, роли и правила у процесса «в таблицах»

Что делаем

• Собираем все таблицы/шаблоны/формы и сводим их в один реестр;
• Выписываем сущности (например: Заявка, Контрагент, Документ, Согласование, Пользователь);
• Для каждой сущности фиксируем поля (тип, обязательность, допустимые значения) и статусы (черновик → в работе → согласование → подписано → архив);
• Описываем роли: инициатор, исполнитель, согласующие (юрист/финансы/безопасность), админ;
• Фиксируем правила и исключения: кто что может редактировать, где пороги сумм, какие SLA.

‍

Артефакты на выходе

• «Инвентаризация» (1 табличка: сущность → поля → источник → ответственный)
• Карта ролей и переходов статусов
• Список интеграций (куда и что руками копируем сейчас)
  

Риск/лайфхак: не копите мусор и неиспользуемое. Делайте «инвентаризацию-лайт»: только то, с чем работали за последние 3–6 месяцев.

День 3 — Модель данных

Цель: нормализовать данные, убрать дубли и заложить связи

Что делаем

• Определяем ключи (ID): GUID/автоинкремент
• Связи 1:N: например, Контрагент — Заявки, Заявка — Файлы, Заявка — Согласования
• ‍Валидируем поля: типы, маски (ИНН, e-mail), диапазоны, обязательность
  

Совет: не делайте «таблицу-монолит». Лучше 4–6 нормальных сущностей и связи.

День 4 — Формы и списки

Цель: сделать удобный интерфейс для ввода и просмотра

Что делаем

• Карточка «Заявка»: группируем поля по секциям (Основное / Контрагент / Финансы / Файлы)
• ‍Списки/реестры: быстрые фильтры (по статусу, исполнителю, дедлайну), сохраненные представления: «Мои», «Просроченные», «На согласовании»
• Включаем поиск по номеру/контрагенту, быстрые действия (изменить статус, назначить)
  

Совет: не пытайтесь уместить всё на один экран. «Короткая карточка + вкладки».

День 5 — Процессы (workflow)

Цель: формализовать маршруты и тайминги

Что делаем

• Строим диаграмму статусов: Черновик → В работе → Согласование (юр → фин → безопасность) → Подписано → Архив.
• Заводим правила переходов (кто может, при каких условиях)
• ‍Таймеры: например, юрист — 8 раб. часов, финансы — 4, безопасность — 8
• ‍Уведомления: «назначили на вас», «SLA через 2 часа», «просрочка»
• ‍Эскалация: просрочка > 4 часа → лид/рук
  

Совет: начните с минимального маршрута.

День 6 — Интеграции

Цель: убрать ручной копипаст и замкнуть контуры

Что делаем

• Через Albato/Make подключаем:
  
  • CRM (создавать/обновлять контрагента, тянуть сделки/контакты)
  • ‍ЭДО/подпись (Диадок/Контур/DocuSign): отправка на подпись, получение статуса/файла
  • ‍Почта/мессенджер (инбокс, уведомления, кнопки «принять/отклонить»)
    
• Вебхуки: при смене статуса «Согласовано» отправь карточку в ЭДО; при «Подписано» — положи PDF в хранилище и закрой задачу.
  

Артефакты

• Карта интеграций (триггер → действие → поля)
• Тестовые ключи/связки, логирование ошибок
  

Совет: для первой версии хватит 2 интеграций. Остальное - после запуска.

День 7 — Доступы и безопасность

Цель: роли, права, аудит

Что делаем

• RBAC-матрица (пример):
  
  • Инициатор: создать/читать свои; редактировать до «В работе»
  • ‍Исполнитель: читать всё; редактировать назначенное
  • ‍Юрист/Финансы/ИБ: читать всё; менять только поля своей секции
  • ‍Админ: полный доступ
    
• Гранулярные права: запрет редактировать финполя не по роли, маски ПДн.
• ‍Журнал действий: кто/что/когда; журнал входов
• ‍Бэкап/экспорт: включить регулярную выгрузку (CSV/JSON) по расписанию
  

Совет: правило «минимально необходимый доступ» с первого дня.

День 8 — Отчёты и дашборды

Цель: видеть прогресс и узкие места

Что делаем

• Канбан по статусам (кол-во/сумма)
• ‍KPI-дашборд: lead time/по этапам, % SLA, просрочки, топ-узкие места
• Экспорт: сводка в CSV/Sheets по расписанию
  

Совет: не делайте 20 графиков. Лучше выбрать три метрики, которые влияют на деньги/срок.

День 9 — Тест-прогон (end-to-end)

Цель: убедиться, что процесс работает «сквозняком»

Что делаем

• Прогоняем 10–15 кейсов: маленькие/средние/крупные суммы, с ветвлениями
• Проверяем нотификации, SLA-таймеры, эскалации, интеграции и права
• Заводим реестр багов: приоритет, шаги воспроизведения, владелец, срок
  

Совет: тестируйте двумя ролями минимум (инициатор + согласующий).

День 10 — Запуск

Цель: включить пользователей и не утонуть в вопросах

Что делаем

• Онбординг 30 минут:
  
  • где форма заявки,
  • как смотреть свои задачи,
  • что делать при просрочке/ошибке,
  • куда писать (канал поддержки).
    
• Чек-лист поддержки: кто дежурит, как заводить баги/улучшения, время реакции
• ‍Бэкап-план: ежедневная выгрузка, инструкция «катастрофа/откат»
• Назначаем итерацию 2.0 через 2 недели (разбор фидбэка и приоритетов)
  

Совет: замерьте метрики до и после (минимум 2 недели) — будет чем защищать эффект.

Частые ошибки (и как их обойти)

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

1) «Перенесли таблицу как есть»

Симптомы: одна «толстая» сущность, склейка разнородных данных в одной таблице, свободный ввод статусов, текст вместо справочников, скопированные листы «Версия 1/2/3».

Почему это больно: дубли, расхождения, невозможность нормально фильтровать/соединять, ломается отчётность и автоматизация.

Как обойти (чек-лист нормальной модели данных):

• Разделите на сущности: например, Заявка, Контрагент, Договор, Платёж, Файл
• ‍Связи: 1:N (Заявка→Файлы), N:M через связующую таблицу (Заявка↔Услуги)
• ‍Ключи: стабильные ID (GUID/автоинкремент), внешние ключи вместо текстовых «склеек»
• ‍Справочники: статусы, типы заявок, валюты - только из выпадающих списков
• ‍Валидации: типы (число/дата/email), диапазоны, маски (ИНН/телефон), обязательные поля
• ‍Служебные поля: created_at, updated_at, created_by, status_changed_at
• ‍Аттачи отдельно: файлы - всегда в отдельной связанной сущности
• ‍Импорт по мэппингу: CSV→поля, конверсия типов, проверка дубликатов
  

2) Вендор-лок (заперлись в платформе)

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

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

Как обойти (стратегия «выход есть с первого дня»):

• Юридически: в договоре пропишите право и процедуры экспорта данных/схем/файлов; SLA на выгрузку по требованию
• ‍Технически: проверьте наличие
  
  • полного экспорта данных (CSV/JSON/Parquet) с файлами
  • ‍экспорта схемы/воркфлоу (JSON/BPMN/YAML)
  • ‍публичного API (+ OpenAPI-спека), вебхуков, OAuth2/JWT
    
• Еженедельный бэкап-выгрузка: автоматический dump в ваше хранилище (S3-совместимое/Объектное хранилище)
• ‍Интеграции через «ваш» слой: унифицируйте обмен через Albato/Make или свой API-шлюз, чтобы не приковываться к одному коннектору
• ‍Критичные правила — вне «магии»: храните пороги, матрицы маршрутизации, прайс-таблицы в читаемых справочниках/JSON, а не «зашитых» ветках визуального конструктора
• ‍Документируйте модель данных: живой README с полями/типами/связями и примерами запросов

Контроль качества:

• Тест «эвакуации»: раз в месяц выгрузите 100% данных и восстановите в песочнице.
• Тест «падения коннектора»: временно выключите интеграцию — у вас есть запасной маршрут?
  

3) Хаос в доступах

Симптомы: «всем всё видно», шэринг по ссылкам, админ-доступы лежат в общем чате, непонятно «кто что правил».

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

Как обойти (минимальный стандарт безопасности):

• RBAC/минимально необходимый доступ: роли по функциям (инициатор, исполнитель, юрист, финансы, ИБ, админ). Нет роли — нет доступа
• ‍Матрица прав (роля × действие × уровень): чтение/создание/изменение/удаление; разнесение по полям (финансовые поля доступны только роли «Финансы»)
• ‍SSO и аудит: вход только через корпоративный SSO (SAML/OIDC); включён журнал действий (кто/что/когда), логин-трейсы
• ‍Секреты/токены: в KMS/Lockbox; ротация раз в 60–90 дней; запрет на шэринг в чатах
• ‍Проверка доступов раз в квартал: выгрузка «кто к чему имеет доступ», подтверждение менеджерами
• ‍Разделение сред: dev/test/prod; в проде — только через change-процедуры
• ‍Break-glass: отдельная аварийная роль с MFA + логированием и пост-review
  

RU-стек (быстрый старт в РФ)

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

1) Лендинг + лиды

• Tilda - сайт/лендинг, формы заявок
• Хранилище лидов: Notion или Google Sheets (достаточно на старт)
• Интеграции: Albato (Tilda → CRM/почта/телеграм)
• ‍Апгрейд позже: платёжка (ЮKassa/CloudPayments), аналитика (Я.Метрика)
  

Мини-связка: Tilda → Albato → Sheets/Notion → Telegram/e-mail

2) Внутреннее приложение/процесс

• Directual или AppMaster — визуальная модель данных, формы, роли, API
• Интеграции/роботы: Albato (вебхуки, расписания)
• ‍Апгрейд позже: вынести файлы в S3-совместимое хранилище, добавить SSO
  

Мини-связка: Directual/AppMaster (данные+UI) ↔ Albato (интеграции).

Когда выбрать Directual: web-приложение с таблицами/формами/ролями и API.
Когда выбрать AppMaster: нужно web + мобильные клиенты и генерация бэкенда.

3) Подпись и ЭДО

• Диадок или Контур — отправка/получение, статусы, архив
• Склейка: Albato (событие в приложении → отправка в ЭДО → статус назад)
  

Мини-связка: Directual/AppMaster → Albato → Диадок/Контур (+файл в хранилище).

4) Чат-бот/уведомления

• Botmother — конструктор ботов (Telegram/ВК и т.д.)
• Данные: Directual/AppMaster/Sheets (что удобнее на старт)
• ‍Сценарий: форма в боте → запись в базу → нотификация менеджеру
  

Мини-связка: Botmother → Albato → база (Directual/Sheets) → уведомления.

5) Интеграции и автоматизации

• Albato — оркестратор: вебхуки, API, расписания, алёрты.
• ‍Совет: все внешние системы подключайте через Albato как через «ваш» слой — меньше связей «впрямую», проще поддержка.
  

Мини-связка: Источник (CRM/почта/бот) → Albato → Приёмник (ЭДО/база/e-mail).

Итог

Начинайте не со «стека мечты», а с одной боли и одной связки. Для РФ это Tilda/Albato + Directual/AppMaster (+ Диадок/Контур по нужде). Для глобального рынка - WeWeb/Softr/Glide + Airtable/Notion + Make/Zapier (+ DocuSign). Сразу заложите выход (экспорт, API, бэкап) и порядок (роли, аудит-лог). Доведите MVP до первых платящих, измерьте эффект (lead/cycle time, SLA), и только потом наращивайте интеграции, S3-хранилище, SSO и очереди.