Excel вырос из бизнеса, но бизнес вырос из Excel: почему внутренние системы пора собирать иначе

Почти каждый бизнес начинается с таблицы.

Не с CRM, не с ERP, не с технического задания на разработку, а с обычной таблицы. В одной вкладке — клиенты. Во второй — заявки. В третьей — оплаты. Потом появляется отдельный файл для задач, отдельный файл для склада, отдельный файл для отчётов и ещё один файл “финальный_версия_точно_последняя”.

И в этом нет ничего плохого. Excel и Google Таблицы стали универсальным языком бизнеса именно потому, что они понятны почти всем. Не нужно объяснять менеджеру, что такое база данных. Не нужно просить разработчика добавить новое поле. Не нужно ждать релиз. Открыл таблицу, добавил столбец, внёс данные — работа поехала дальше.

Но в какой-то момент таблица перестаёт быть просто таблицей.

К ней подключают Telegram-бота. Менеджеры начинают менять статусы заявок. Руководитель хочет видеть отчёт по отделам. Появляется необходимость ограничить доступ: один сотрудник должен видеть только свои сделки, другой — всю базу, третий — только отчёты. Потом кто-то случайно удаляет важный столбец. Потом данные начинают дублироваться. Потом становится непонятно, где актуальная версия.

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

Таблицы хорошо работают, когда данные простые.

Например, есть список клиентов:

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

В этот момент таблица становится частью бизнес-процесса.

А бизнес-процесс — это уже не просто ячейки. Это правила, роли, связи, история изменений, автоматизации и интеграции.

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

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

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

Excel и Google Таблицы не плохие инструменты. Наоборот, они настолько удобны, что бизнесы используют их сильно шире изначального сценария. Таблица становится CRM, складской системой, базой знаний, планировщиком задач, реестром оплат, каталогом товаров и backend-частью для бота.

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

У бизнеса появляются новые требования:

Нужны связи между данными. Клиент может иметь несколько заявок. У заявки может быть ответственный менеджер. У менеджера может быть отдел. У товара может быть поставщик. У заказа может быть несколько позиций.

В обычной таблице такие связи часто имитируются текстом: “Иван Петров”, “ООО Ромашка”, “Заявка 143”. Но для системы это просто строки. Она не понимает, что это связанные сущности.

Нужны права доступа. В реальной компании не все должны видеть всё. Менеджеру не всегда нужно видеть финансовые показатели. Подрядчику не нужно видеть всю клиентскую базу. Стажёру не нужно иметь возможность удалить таблицу.

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

Нужен API. Как только у бизнеса появляются сайт, бот, личный кабинет, автоматизация или AI-агент, данным нужен программный доступ. Не “скачать Excel и загрузить обратно”, а нормальный интерфейс, через который другие сервисы могут читать и записывать данные.

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

Когда таблицы начинают ломаться, часто появляется идея: “А давайте напишем свою систему”.

На бумаге звучит логично. Сделаем свою CRM, учтём все процессы, добавим нужные роли, интеграции и отчёты.

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

Нужно спроектировать базу данных. Сделать интерфейс. Настроить авторизацию. Добавить роли. Реализовать импорт и экспорт. Сделать API. Продумать фильтры, сортировки, поиск, историю изменений. Потом добавить отчёты. Потом выяснить, что процесс изменился. Потом переделать статусы. Потом добавить новое поле. Потом ещё одно представление. Потом интеграцию с ботом. Потом выгрузку для бухгалтерии.

В итоге бизнес хотел “простую CRM”, а получил полноценный программный продукт, который нужно разрабатывать, поддерживать и развивать.

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

Многим не нужна разработка с нуля. Им нужна промежуточная ступень между таблицей и полноценной системой.

На рынке давно появился отдельный класс инструментов: CRM, no-code базы данных и low-code платформы для внутренних систем.

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

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

В последние годы этот подход стал особенно актуален. Бизнесу нужно быстро собирать внутренние инструменты, запускать процессы, подключать автоматизации и AI-агентов. Разработка с нуля часто слишком медленная, а обычные таблицы уже слишком слабые.

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

Представим простую CRM.

В Excel она может выглядеть так:

Клиент | Телефон | Статус | Менеджер | Сумма | Комментарий

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

Правильнее разложить данные на сущности:

Клиенты

Заявки

Менеджеры

История действий

Такой подход сразу даёт порядок. Клиент не дублируется в десяти строках. Заявки связаны с клиентом. Ответственный выбирается из списка сотрудников. Статус становится не случайным текстом, а заданным значением. Историю можно отследить.

И самое важное: эти данные можно использовать не только руками через интерфейс.

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

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

Раньше API казался чем-то для разработчиков. Сейчас он становится базовой потребностью даже для небольших команд.

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

API — это мост между данными и внешними сервисами.

Например:

Без API всё это превращается в ручную работу, выгрузки, копирование и пересылку файлов. С API данные начинают жить внутри процесса.

Именно поэтому в современных no-code базах данных API должен быть не дополнительной функцией “для технических специалистов”, а частью продукта по умолчанию.

Airtable показал, что база данных может быть понятной обычному пользователю. Не нужно открывать SQL-клиент, писать запросы и думать про таблицы в инженерном смысле. Можно работать визуально: создавать поля, связывать записи, настраивать представления, строить интерфейсы, запускать автоматизации.

Это сильная идея.

У Airtable есть несколько важных преимуществ:

Зрелая экосистема. Много шаблонов, интеграций, сценариев использования, обучающих материалов и внешних специалистов.

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

Автоматизации и интеграции. Данные можно связывать с другими сервисами: почтой, календарями, мессенджерами, CRM, аналитикой и AI-инструментами.

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

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

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

Но у этого подхода есть и ограничения для российского рынка.

Для части компаний важны русский интерфейс, хранение данных в российской юрисдикции, понятная поддержка, локальные сценарии и стоимость в рублях. Кроме того, не всем нужен огромный enterprise-комбайн. Иногда бизнесу нужен более простой инструмент: создать базу, таблицы, поля, пригласить команду и сразу получить API.

Мы пришли к этой проблеме через практические задачи: боты, внутренние инструменты, CRM, автоматизации, базы клиентов, каталоги, заявки и рабочие процессы.

Во многих проектах повторялся один и тот же сценарий.

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

Каждый раз приходилось выбирать между двумя крайностями:

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

Идея простая: пользователь создаёт организацию, базу, таблицы и поля через интерфейс, а система сразу даёт структуру данных, роли, представления и REST API.

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

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

В обычной таблице всё начинается просто:

В системе это можно превратить в более устойчивую структуру.

Создаётся база “Продажи”. Внутри — таблицы “Клиенты”, “Заявки”, “Менеджеры”, “Услуги”. Для каждой таблицы настраиваются поля: текст, число, дата, селект, чекбокс, email, URL, файл, пользователь, JSON и другие типы.

Дальше можно сделать несколько представлений:

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

Затем подключается API.

Telegram-бот создаёт заявку. Сайт отправляет форму. Автоматизация обновляет статус. Разработчик получает список записей через HTTP-запрос. AI-агент сохраняет результат обработки обращения.

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

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

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

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

Для этого нужна база.

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

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

Например:

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

Главная ошибка — противопоставлять таблицы и базы данных.

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

Проблема не в табличном интерфейсе. Проблема в том, что под ним часто нет нормального фундамента.

Будущее внутренних инструментов — не в том, чтобы отказаться от таблиц. Наоборот, таблица останется одним из самых удобных интерфейсов для работы с данными.

Но под таблицей должна быть структура:

Тогда таблица перестаёт быть файлом и становится рабочим интерфейсом к базе данных.

No-code базы данных особенно полезны там, где процесс уже понятен, но писать отдельную систему ещё рано или слишком дорого.

Например:

Малому бизнесу. Для заявок, клиентов, услуг, оплат, складских остатков, контрагентов и внутренних задач.

Агентствам. Для ведения проектов, клиентов, контент-планов, производственных процессов и отчётности.

Стартапам. Для MVP, админок, каталогов, ранних CRM и проверки гипотез без долгой разработки.

Разработчикам. Как быстрый backend для прототипа, внутреннего инструмента, бота или личного кабинета.

No-code специалистам. Как база данных для связки с n8n, ботами, формами, сайтами и AI-агентами.

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

Важно сказать честно: не каждую таблицу нужно срочно переносить в отдельную систему.

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

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

Переход нужен не тогда, когда “Excel устарел”. Он не устарел.

Переход нужен тогда, когда таблица стала критичной для бизнеса.

Есть несколько признаков:

Если эти признаки появились, бизнес уже вырос из Excel.

Скорее всего, внутренние системы будут собираться всё более модульно.

Не обязательно писать всё с нуля. Не обязательно покупать тяжёлую CRM и подстраивать бизнес под неё. Не обязательно держать всё в таблицах до тех пор, пока они не начнут мешать работе.

Будет нормой собирать процесс из готовых слоёв:

В такой модели no-code база данных становится центральным слоем. Она хранит состояние бизнеса и связывает между собой людей, интерфейсы, ботов, сайты и автоматизации.

Для пользователя это всё ещё выглядит как понятная таблица. Для системы — это уже структурированная база данных.

И именно в этом переходе сейчас находится большое количество компаний.

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

Excel вырос из бизнеса, потому что дал людям простой способ управлять данными без разработчиков. Это был и остаётся один из самых важных инструментов для компаний.

Но теперь сам бизнес вырос из Excel.

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

Ей нужен фундамент: структура, права, API, история изменений и возможность работать в команде.

Поэтому следующий этап — не отказ от таблиц, а их эволюция.

Таблица остаётся интерфейсом. База данных становится основой.API связывает всё с внешними сервисами.А бизнес получает возможность собирать внутренние системы быстрее, дешевле и понятнее.

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