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

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

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

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

Для демонстрации сделана таблица на 300 строк: в ней 38 сотрудников, 6 отделов и 12 проектов. Этого достаточно чтобы показать возможности Tables и не перегрузить вашу голову, когда вы будете знакомиться с обзором.

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

Чтобы вы лучше понимали таблицу и ее проблему, рассмотрим первую строку: Анна Смирнова подала заявку в проекте «Редизайн корпоративного сайта». В таблице возникает куча данных: отдел Анны, должность, контакты, название проекта и имя руководителя.

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

У нас 300 строк на 38 человек — почти по 8 заявок на каждого сотрудника.

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

• статусы, типы и приоритеты будут вводиться непосредственно в строки;

• изменение одной сущности потребует исправить несколько записей и так далее.

Иными словами, наша таблица (а если честно — это просто список) вообще не соответствует структуре процесса и не динамична.

Чтобы превратить перегруженный список в связанные и удобные сущности, нам и пригодится MWS Tables.

Подготовка таблицы

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

И начнем с того, что импортируем таблицу в MWS Tables.
Для этого создадим новое пространство.

Внутри, в левом верхнем углу найдем кнопку «Импорт» и добавим нашу таблицу.

Важно знать: стандартные настройки импорта делают данные обычным текстом, или, как это называется в MWS Tables, «Длинный текст». Чтобы наш реестр (далее в тексте под ним имеется в виду основная таблица, импортированная в MWS Tables) работал корректно, вам будет нужно задать правильные типы полей: покажу это на примере столбца «Дата заявки».

Для этого нажимаем на три точки у соответствующего столбца и выбираем «Изменить параметры поля».

Внутри типа поля нам нужен раздел «Дата». Нажимаем «ОК», и данные автоматически конвертируются. Далее по тому же принципу настраиваем следующие столбцы:

Есть особая настройка: тип «Выбрать». Это поле ограничивает значение заранее заданным набором вариантов — скажем, типами заявок или статусами. Иногда его нужно выставлять вручную, но в этом случае, благодаря изначально структурированным данным, система сама определила все восемь типов заявок.

Пока что я намеренно не трогал некоторые другие поля — с ними мы позже поработаем другим инструментом под названием «Магическая ссылка», которая создает поле связи с записями других таблиц.

Автор как сущность

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

Для этого нужно создать отдельную таблицу сотрудников внутри нашего пространства. В проводнике слева выбираем «Добавить» → «Новая таблица», назовем ее «Сотрудники».

Далее переименуем столбцы и зададим им правильный тип данных.

• «Сотрудник» → «Текст в одну строку»;

• «Отдел» → «Выбрать» (добавим «Маркетинг», «Продажи», «HR», “ИТ”, «Финансы и Операции»);

• «Должность» → «Текст в одну строку»;

• «E‑mail» → “Электронная почта”.

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

Скопируем содержимое столбца № 1 и перенесем в таблицу MWS Tables. 

Далее мы возвращаемся в исходную таблицу и переходим в столбец «Автор», добавим там новый столбец «Автор‑связь» и присвоим тип поля «Магическая ссылка».

Эта магическая ссылка связывает сущности из разных таблиц.
Мы привяжем к ней новую таблицу «Сотрудники» и настроим первую строку: для этого нужно в новом столбце нажать на плюсик и просто выбрать нового сотрудника из картотеки. Дополнительные данные о нем я предварительно заполнил.

Осталось проверить, появилась ли связь с той стороны, в таблице сотрудников. И та‑дам, так оно и есть! В таблице автоматически подтянулись данные из общего реестра.

Нам осталось заполнить, и чтобы не вводить вас в ужас ручной работы, мы схитрим: просто скопируем из исходной таблицы все 300 строк с именами и вставим в столбец «Автор‑связь». Поскольку значения совпадают с именами записей в справочнике, MWS Tables сопоставит их и создаст связи сразу для всего столбца.

Данные подтянулись автоматически, и нам не пришлось вручную назначать каждого автора!

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

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

Исполнители

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

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

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

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

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

И вот наконец у нас появился полноценный справочник сотрудников.
Осталось убрать лишние данные, чтобы реестр перестал быть таким громоздким, а данные об отделе/почте и должности также могли автоматически обновляться. Для этого я сперва полностью заполнил таблицу сотрудников (тем же методом копипасты из нашей таблички, выжатой в ChatGPT).

А теперь в реестре добавим еще один столбец («Автор — поиск») и присвоим ему тип «Поиск». Там выбираем таблицу «Сотрудники, автор», а во втором поле выбираем столбец «Отдел».

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

Нам осталось только убрать старые столбцы. Но лучше их не удалять, просто скрыть — нажимаем на кнопку «Скрыть» и выбираем поля (я специально дополнил их название, чтобы было проще ориентироваться).

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

Но это полдела. 

Наводим порядок в проектах

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

Для этого я попросил ChatGPT вынести все проекты и их руководителей.

А теперь в самом MWS Tables мы добавим еще одну таблицу через проводник (левая панель) и назовем ее «Проекты». Туда импортируем табличку из скрина выше.

И сразу же добавим новый столбик, «Руководитель — связь», дадим ему магическую ссылку с таблицей сотрудников.

А далее привязываем карточку сотрудника.

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

Графу, что была ниже, скрываем.

Теперь те же действия провернем с самими проектами, но их уже привяжем к таблице проектов (а не сотрудников, как выше), должно получиться вот так:

Осталось связать это с реестром: там создаем новый столбец с названием «Проект — связь», выбираем тип «Магическая ссылка» и связываем с таблицей проектов.

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

А теперь проделаем аналогичную настройку с руководителями проекта по конфигурации на скриншоте.

А далее мы скрываем старые поля, а новым задаем стандартные названия.

Наш реестр стал полноценной базой данных и готов к бою!

А теперь покажу, на что он стал способен.

Разные интерфейсы одного реестра

Попробуем иначе взглянуть на реестр.
Для этого создадим новое представление, тип «Сетка».

Вы увидите точно такую же таблицу что и в реестре: это, по сути, быстрая копия.

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

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

Что за заявка → кто создал → к какому проекту относится → кто выполняет → состояние → срок.

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

А теперь поиграемся посерьезней.

Канбан по статусам

Сперва в основном реестре перенес столбец «Статус» как можно левее, а затем сверху выбираем «Новое представление» → «Канбан‑доска». Туда автоматически распределятся статусы.

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

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

Форма подачи заявки

Сделаем простой экран для формирования новых заявок, чтобы не вписывать строки каждый раз вручную. Нам понадобится «Добавить представление» → «Форма».

Там слева выбираем «Сетка» и создаем форму.
И получаем штуковину, очень похожую на Google Forms, которую очень просто заполнять.

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

В итоге

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

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

Можно ли назвать результат полноценным приложением? Для нашего сценария — вполне. У него есть структура данных, связи между сущностями, интерфейс подачи заявки и отдельный экран для управления процессом. Все это мы собрали без собственного бэкенда, фронтенда и написания кода.

Но MWS Tables никак не отменяет проектирование.
Больше всего времени у нас заняло понимание того, какие сущности существуют в процессе, где должны храниться данные и как их правильно связать. Чем сложнее правила, права доступа, согласования и интеграции, тем быстрее проект приблизится к границе возможностей no‑code‑платформы.

Эксперимент удался.
До встречи в новых обзорах!