Как создать внутренний инструмент: админ-панели, согласования и замена таблиц
Чтобы создать внутренний инструмент, выберите один неудобный процесс — обычно общую таблицу, цепочку писем или чат, которые выполняют работу базы данных, — и превратите его в небольшое приложение с нормальной формой, списком со статусами, правами для каждой роли и историей того, кто что менял. ИИ-конструктор может выдать рабочую первую версию за один день. Успех зависит от того, насколько узким остаётся охват одним процессом и насколько инструмент создаётся вместе с людьми, которые будут пользоваться им каждый день.
Что считается внутренним инструментом
Внутренние инструменты — это незаметное программное обеспечение, на котором держится бизнес. Частые типы:
| Тип | Что делает | Что заменяет |
|---|---|---|
| Админ-панель | Поиск, просмотр и редактирование записей (клиенты, заказы, пользователи) | Прямые правки в базе данных, огромная таблица |
| Заявка и согласование | Один человек подаёт, другой одобряет или отклоняет | Цепочки писем, сообщения «можешь подтвердить?» |
| Трекер | Элементы, проходящие стадии (найм, активы, баги, доставки) | Таблица с цветным столбцом статусов |
| Чек-лист или инструмент онбординга | Обязательные шаги с ответственными и сроками | Копия документа для каждого нового сотрудника или клиента |
| Операционная панель | Текущие цифры и исключения на одной странице | Еженедельный отчёт, который кто-то собирает вручную |
Другие идеи для старта — в гиде идеи внутренних инструментов для команд.
Стоит ли вообще это делать?
Оставьте таблицу, если её ведёт один человек, данных немного, а ошибка стоит мало. Создавайте инструмент, если вы замечаете такие признаки:
- Люди перезаписывают изменения друг друга, или никто не знает, какая копия актуальна
- Некоторым людям нужно видеть или редактировать только часть данных
- Вы написали страницу инструкций по работе с таблицей
- Смена статуса должна кого-то уведомлять, и уведомления постоянно пропускают
- Нужен журнал аудита — кто и когда это одобрил
Есть и промежуточный вариант. Платформы low-code для внутренних инструментов (Retool, интерфейсы Airtable, Softr и другие) дают готовые блоки поверх ваших данных. Они подходят, когда данные уже лежат в поддерживаемой базе или таблице и вам нужны экраны с drag-and-drop. ИИ-приложение больше подходит, когда процесс специфичен, вы хотите, чтобы инструмент выглядел и работал именно так, как нужно команде, или хотите владеть кодом. Об общем вопросе см. собственная разработка или покупка ПО для малого бизнеса.
Сначала проектируйте процесс, потом экраны
Опишите процесс как короткую историю до того, как писать запрос. Для инструмента согласования расходов:
- Сотрудник подаёт расход: сумма, категория, дата, описание, фото чека.
- Его руководитель получает уведомление и одобряет или отклоняет с комментарием.
- Расходы сверх лимита также требуют одобрения финансового отдела.
- Финансовый отдел отмечает одобренные расходы оплаченными пачкой раз в неделю.
- Каждый видит статус своих расходов; финансовый отдел видит все.
Из этой истории получаются:
- Данные: расходы, пользователи, роли, согласования (кто, решение, комментарий, дата), вложения.
- Статусы: отправлено → одобрено руководителем → одобрено финансами → оплачено, или отклонено.
- Роли: сотрудник, руководитель, финансы, администратор.
- Правила: порог суммы, кто может перевести элемент в каждый статус.
- Экраны: форма отправки, «мои расходы», «ждут моего одобрения», таблица всех расходов для финансов, страница деталей с историей.
Опишите процесс в таких терминах, и ИИ сможет собрать правильную вещь с первой попытки.
Права доступа и история
Внутренние инструменты часто хранят чувствительные данные — зарплаты, данные клиентов, деньги. Два правила:
- Проверяйте роли на сервере для каждого действия. Руководитель не должен мочь одобрить собственный расход, обращаясь напрямую к методу одобрения.
- Записывайте историю. Сохраняйте каждое изменение статуса и правку с тем, кто и когда её сделал. Это снимает большинство споров «кто это менял?» и незаменимо, когда что-то идёт не так.
Решите, как люди будут входить. Вход через корпоративные аккаунты Google или Microsoft удобен для команд, которые уже ими пользуются; email и пароль работают везде. В любом случае ограничьте регистрацию, чтобы войти мог только ваш коллектив.
Первый запрос, который работает
Создай внутреннее приложение для согласования расходов для компании на 25 человек. Сотрудники подают расход с суммой, валютой, категорией (поездки, питание, ПО, оборудование, другое), датой, описанием и загрузкой фото чека. Руководитель видит список «Ждёт моего одобрения» и может одобрить или отклонить с комментарием. Расходы сверх 500 долларов также требуют одобрения человека с ролью финансиста. Финансовый отдел видит таблицу всех расходов с фильтрами по статусу, человеку и месяцу и может отметить одобренные расходы оплаченными. Каждое изменение статуса записывается с тем, кто и когда его сделал, и показывается как хронология на странице расхода. Роли: сотрудник, руководитель, финансы, администратор — проверяются на сервере при каждом действии. Всё храним в базе данных и заполняем реалистичными примерами. Простой, плотный и быстрый интерфейс — это рабочий инструмент, а не маркетинговый сайт.
Шаги сборки
- Основная таблица и форма для ключевой записи, с реалистичными тестовыми данными, чтобы поиск и фильтры были очевидно рабочими.
- Статусы и переходы, включая то, кто может перевести элемент в каждое состояние.
- Роли и вход, доступ только для вашей команды.
- Журнал истории на каждой записи.
- Уведомления — письмо или сообщение в чате, когда нужно чьё-то действие.
- Импорт существующих данных из таблицы. Как превратить таблицу в приложение описывает очистку и импорт.
- Пилот с двумя-тремя реальными пользователями на неделю, прежде чем открывать инструмент всем.
- Отключите старый процесс в заранее назначенную дату. Две системы, работающие параллельно, не вызывают доверия ни к одной из них.
Заставить людей пользоваться
Много внутренних инструментов работают идеально и всё равно терпят неудачу, потому что люди продолжают делать по-старому.
- Создавайте вместе с пользователями. Понаблюдайте, как кто-то выполняет задачу сегодня, прежде чем проектировать новую версию.
- Сделайте быстрее старого способа. Если отправка занимает дольше, чем написать сообщение, люди будут продолжать писать сообщения.
- Плотность важнее красоты. Операторам удобнее таблицы с хорошими фильтрами и формы, управляемые с клавиатуры, чем большие карточки и пустое пространство.
- Следующее действие — первым. «Ждёт меня» должно быть первым, что видят люди.
Частые ошибки
- Перенос всей таблицы целиком. Переведите один болезненный процесс; остальное пока оставьте в таблице.
- Нет владельца. Кто-то должен отвечать за изменения и исправления после запуска.
- Права как запоздалая мысль. Добавлять роли в готовый инструмент сложнее, чем начать с них.
- Пропуск журнала аудита — и потом его отсутствие, когда впервые пропадут деньги.
- Публикация на публичном адресе без входа. Всё внутреннее должно требовать входа.
Поддержка после запуска
Процесс меняется каждые несколько месяцев — появляется новый шаг согласования, новая категория, новая команда. Заложите это с самого начала:
- Храните настройки в таблицах, а не в коде. Категории, пороги и назначения согласующих в базе данных может поменять администратор без пересборки.
- Собирайте запросы в одном месте. Простая ссылка «предложить изменение» в инструменте лучше запросов, разбросанных по чатам.
- Экспортируйте регулярно. CSV-выгрузка основных таблиц означает, что данные никогда не окажутся в ловушке, и упрощает отчётность на конец месяца.
- Проверяйте после каждого изменения. Пройдите заново отправку, одобрение и отклонение после любой правки процесса, потому что ошибки прав чаще всего появляются именно там.
Расходы
Внутренний инструмент, созданный с помощью ИИ, требует оплаты хостинга, базы данных, файлового хранилища, если люди загружают документы, и, возможно, почтового или мессенджер-сервиса для уведомлений. Для инструмента, которым вы владеете, обычно нет лицензий за место, что важно, когда много редких пользователей нуждаются в доступе. Постоянная стоимость — это время человека, который его поддерживает.
Создание с Mythex
Внутренние инструменты хорошо подходят для Mythex. Вы описываете процесс, агент строит его в живом превью, добавляет базу данных Postgres для записей и файловое хранилище для загрузок, например чеков. В документации есть стартовые запросы на странице сценария внутреннего инструмента и сценария админ-панели. Коллеги могут помогать создавать его в вашем рабочем пространстве без оплаты за место.
Два момента. Вход для вашей команды, которая пользуется инструментом, — часть приложения, которое вы создаёте, с выбранным вами подходом; он отделён от аккаунтов Mythex. И Mythex не включает встроенных интеграций Salesforce, HubSpot или Slack для самого приложения: они подключаются через их API вашими ключами. Для стартового запроса попробуйте шаблоны трекер согласований или внутренняя админ-панель, а если вам нужны в основном графики, посмотрите как создать дашборд.
Вопросы
Что такое внутренний инструмент?
Внутренний инструмент — это программа, которой пользуется ваша команда для ведения бизнеса, а не клиенты: админ-панель, поток согласования, трекер, операционная панель. Чаще всего он начинается с таблицы или почтового ящика, которые стали трудно вести.
Когда стоит заменить таблицу внутренним инструментом?
Когда несколько человек редактируют её и перезаписывают изменения друг друга, когда нужно ограничить, кто что может менять, когда вы постоянно пишете инструкции, как работать с таблицей, или когда ошибки в ней стоят реальных денег. Если таблицу ведёт один человек и ошибки недороги, оставьте таблицу.
Можно ли создавать внутренние инструменты без разработчика?
Да. ИИ-конструкторы приложений и платформы low-code для внутренних инструментов позволяют не-разработчикам создавать рабочие админ-панели, трекеры и потоки согласования. Заранее подумайте, кто будет поддерживать инструмент, потому что процессы меняются, и инструмент должен меняться вместе с ними.
Как контролировать, кто что может делать во внутреннем инструменте?
Назначьте каждому пользователю роль, например заявитель, согласующий или администратор, и проверяйте эту роль на сервере перед каждым действием, а не только прячьте кнопки. Ведите журнал того, кто и что менял и когда, чтобы ошибки можно было отследить.