статья · 24.10.2026
Excel держится в компаниях не потому, что он хорош, а потому что альтернатива кажется большой стройкой. На деле начать можно с одного процесса и трёх экранов. Разберу порядок шагов и границы минимальной версии.
Сначала это удобно: файл, вкладки, пара формул. Через год файлов пять, версии называются «итог_финал_2_правки», а человек, который понимает формулы, уходит в отпуск.
Дальше появляются признаки, знакомые почти любому малому бизнесу.
Проблема не в Excel как инструменте. Проблема в том, что файл не разграничивает доступ, не хранит историю изменений и не показывает, кто за что отвечает. Каждый новый сотрудник добавляет ещё одну копию, и хаос растёт вместе со штатом.
Если хотя бы два пункта выше про вас, ручной контур уже стоит дороже, чем его обслуживание. Портал не нужен в другом случае: процессов два, сотрудников трое и всё помещается в одну таблицу. Тогда достаточно порядка в файле.
Типичная ошибка — начинать с идеи «сделаем портал для всего». Такой проект обрастает согласованиями и через полгода остаётся на этапе макетов.
Выберите один процесс, у которого есть вход, выход и ответственный. Проще всего начинать с заявок или с базы знаний.
Заявки — если боль в том, что обращения теряются и непонятно, кто их ведёт. Минимальный контур: форма, список, статусы, исполнитель, история. Уже это убирает почту и блокноты.
База знаний — если сотрудники постоянно спрашивают одно и то же, а новичок выходит на самостоятельность месяц. Контур: статьи с поиском, разделы, права на редактирование.
Выбирайте процесс, где результат виден за неделю и где есть человек, готовый пользоваться им каждый день. Всё остальное подождёт: у портала не должно быть функций «на будущее», иначе он не запустится.
Минимальная версия — не «портал без половины функций», а набор, которого хватает для работы. Ниже то, без чего решение не приживётся.
Чего в минимальной версии быть не должно: сложной аналитики, конструктора отчётов, модуля согласований и мобильного приложения. Каждая лишняя функция увеличивает срок и уменьшает шанс, что люди начнут пользоваться.
Доступы проектируются до вёрстки, а не после. Минимальный набор ролей обычно такой: сотрудник, руководитель, администратор, внешний пользователь.
Сотрудник видит свои записи и общие справочники, создаёт и редактирует свои. Руководитель видит свой отдел и отчёты. Администратор управляет справочниками и правами, но не обязательно читает всё содержимое. Внешний пользователь — клиент или подрядчик — видит только то, что ему открыли.
Отдельно решается вопрос чувствительных данных: зарплаты, персональные данные клиентов, договоры. Правило простое: если доступ не нужен для работы, он не выдаётся. Проверить это проще всего на живых примерах — попросить сотрудника открыть чужую заявку и посмотреть, что произойдёт.
Чего не делать: не давать всем роль администратора «на время». Временный доступ почти всегда становится постоянным. Если человеку нужен доступ к данным другого отдела, это решается отдельной ролью с ограничением по разделу, а не повышением прав.
И второе: доступы проверяются на увольнении, а не «когда-нибудь». Уволенный сотрудник с живой учёткой — самая частая дыра во внутренних сервисах, которые собирали без оглядки на процесс.
Крупные системы продаются как решение всех задач сразу: CRM, документы, задачи, обучение, аналитика. На практике вы платите за модули, которые не включите, и подстраиваете процессы под чужую логику.
Типичные последствия: долгое внедрение, консультанты, доработки по прайсу, а сотрудники продолжают вести Excel «на всякий случай». Отдельная проблема — зависимость: уйти с системы сложно, данные выгружаются частично.
Альтернатива не в том, чтобы писать всё с нуля. Разумный путь — небольшой набор своих экранов под конкретный процесс плюс готовые компоненты: авторизация, почта, хранение файлов. Такой контур дешевле, запускается быстрее и не требует обучать людей неделю.
Если процесс действительно крупный — склад, производство, финансы — покупать специализированную систему нормально. Но начинать внутренний портал с комбайна ради трёх экранов заявок смысла нет.
Внутренний сервис — не одноразовый проект. Минимальная версия живёт годами, но только если у неё есть хозяин.
Кто ведёт после сдачи: внутри компании — администратор, который заводит пользователей, правит справочники и собирает пожелания. Снаружи — разработчик на поддержке: исправления, небольшие доработки, обновления зависимостей. Если не назначить первого, второй работает в режиме пожарного.
Что важно передать при сдаче: доступы, схему данных, инструкцию на две страницы и список известных ограничений. Не документацию на восемьдесят листов, а то, что человек откроет в первый день.
Решение живёт, пока процесс не изменился радикально. Если через два года поменялась модель работы, дешевле переписать часть экранов, чем тащить старое. Признак, что пора обновлять, — люди снова обходят интерфейс через Excel.
Почти всегда перенос упирается не в интерфейс, а в таблицы. В них разное написание одной компании, дубли, пустые поля и формулы, которые знает один человек. Переносить это как есть — значит перетащить беспорядок в новую систему.
Импорт делается один раз, скриптом, с отчётом: сколько строк прочитано, сколько загружено, сколько отклонено и почему. Отклонённые разбираются руками — их обычно немного.
К концу недели обычно есть работающий список заявок, куда можно завести настоящую. Это не финальная версия, но уже польза — и видно, где именно процесс сопротивляется.
Если хотите пройти этот путь без лишних покупок, посмотрите внутренние сервисы и остальные услуги. Начать можно с одного процесса и разговора о нём.
Тогда он не лучше, и менять ничего не нужно. Портал нужен, когда в процессе участвуют несколько человек, важна история изменений, доступы различаются, а данные теряются при увольнении. Если ничего из этого нет, порядок в одном файле дешевле любой разработки.
Считается после разбора процесса: количество экранов, интеграции, роли, требования к серверу. Начать с одного процесса дешевле, чем строить портал целиком, потому что вы платите за работающий контур, а не за макет на все случаи. Оценка даётся до начала работ.
Можно, если система уже есть и процесс в неё помещается. Ограничения — лицензии на пользователей, чужая логика статусов и сложность доработок. Если нужен нестандартный процесс, свои экраны часто выходят проще, чем борьба с коробкой.
Для небольшого сервиса хватает одного недорогого сервера: приложение, база, резервные копии. Обслуживание — обновления, бэкапы, мониторинг; это регулярная работа, а не разовая. Можно разместить в облаке, если свой сервер некому администрировать.
Так бывает, если запустить всё сразу или оставить Excel параллельно. Поэтому берётся один процесс, данные переносятся, а старая таблица переводится в режим чтения. Если через две недели люди возвращаются к файлу, значит, интерфейс мешает работе, и это правится.
Опишите процесс в двух предложениях — вернусь со схемой решения и оценкой сроков.