653 документа в одном проекте и два завода под одним ИНН: как мы делали кабинет для поставщика промышленного оборудования

Откуда взялась идея

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

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

Что было в первой версии задачи

Стартовый объем был вполне понятный:

• клиент заходит в кабинет и видит все данные по своему проекту;
• видит, какое оборудование у него есть и где оно установлено;
• общается с менеджером прямо через кабинет;
• подает заявки на ТО.

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

Одна организация - один объект

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

И это не ошибка. Для большинства клиентов такая схема рабочая: одна компания, одна площадка, один набор оборудования. Заказчик и сам потом так сказал: "как правило нет". Усложнять модель заранее, под случай, которого еще никто не видел, значит делать систему тяжелее и дороже для всех ради гипотетического одного.

Что всплыло на запуске

Реальные данные в кабинет начали вносить еще в конце августа, а 9 сентября его развернули на инфраструктуре заказчика, переключили домены, и сотрудники пошли переносить туда все актуальные проекты. Через два дня пришло сообщение: у одного из крупных клиентов под одним ИНН работают два самостоятельных производства. Часть проектов относится к одному, часть к другому. Разные адреса, разные объекты, свое оборудование и свои заявки на ТО. А в системе это одна организация.

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

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

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

Что эта история дала

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

Юрлицо отдельно, производства отдельно

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

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

Права пришлось переписать во всем кабинете

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

Отдельная история - перевод сотрудника. Человек переходит с одного производства на другое, и права прежнего производства у него должны исчезнуть вместе с открытыми сессиями. А заказы, которые он оформлял, остаются за производством и не уезжают вслед за ним. При этом если ему отдельно открыли доступ к стороннему проекту, этот доступ должен сохраниться. Три правила, которые на словах очевидны, а в коде друг другу мешают.

Перенос данных без потерь

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

А вот разнести старые проекты по новым производствам автоматически нельзя. Система не знает и не может знать, на каком заводе стоит конкретная установка. Это бизнес-информация, она есть только у заказчика, поэтому проекты распределяли вручную по его данным. Об этом подробнее в разделе про то, что не получилось.

Аудит безопасности от заказчика

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

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

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

Документы: несколько ТЗ в проекте и тяжелые файлы

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

Проектная документация в нефтепереработке - это не десяток файлов. У одного из проектов, которые сотрудники заказчика перенесли в кабинет, 653 документа. Лимит на проект у нас стоял 500, по просьбе пользователя подняли до 1000 в тот же день. Файлы загружаются напрямую в объектное хранилище, минуя сервер приложения, с прогрессом загрузки и повтором, если что-то оборвалось на середине.

Чат, который живет и в кабинете, и в Telegram

Заказчик общается с инженерами и менеджерами в чате проекта, а чат синхронизируется с группой в Telegram. Люди и так сидят в Telegram, заставлять их ради переписки заходить в отдельное окно - путь к тому, что окно никто не откроет.

Где ИИ помогал, а где мы его останавливали

Код и документацию мы писали с ИИ-агентами, Claude Code и Codex. Роль у них в проекте две, и обе вполне конкретные.

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

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

А теперь про то, где он ошибается. Агент предложил меню для заказчика: слева, с глубокой вложенностью, разделы в разделах в разделах. Логично по структуре данных, визуально перегружено, интуитивно непонятно. Заказчик - это инженер завода, который зашел посмотреть статус заявки на ТО. Ему не нужно дерево, ему нужен пункт "Заявки на ТО". Красиво, логично, по всем правилам. Спасибо, не надо.

В итоге меню плоское: Главная, Основное, Оборудование, Обслуживание и ремонт, Справочник, Обращения, Контакты. Внутри групп по два-три пункта, и каждая роль видит только то, что ей нужно.

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

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

Были и решения, которые не подходили под наш стек: агент предлагал подходы, которые даже после реализации давали не тот результат, которого ждали. Их мы отклоняли.

И одна история в обратную сторону. Когда сотрудники заказчика начали вручную переносить в кабинет все проекты, я предложил сделать для них подключение ИИ-агента через MCP: агент заносит данные сам, человек проверяет. Заказчик ответил, что, может, чуть позже. Тоже нормально. Агента стоит подключать, когда люди сами поняли, какую рутину хотят отдать, а не когда это кажется интересным нам.

Результаты

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

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

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

Сравнение с рынком

Сначала про источники. Ниже цифры из открытых материалов студий и интеграторов за 2026 год. Считают все по-разному: у одних "личный кабинет" - это вход, профиль и один модуль, у других - портал с ЭДО и биллингом. Поэтому смотреть на них надо как на порядок величины, а не как на эталон. Цену нашего проекта не раскрываем, для сравнения ниже наши публичные ориентиры с сайта.

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

Что не получилось

Первое и главное: модель данных пришлось перестраивать после запуска, на живой системе. Мы начали с модели "одна организация - один объект", и для клиента с двумя производствами она оказалась мала. С сегодняшним знанием я бы на старте спросил у заказчика не "кто ваши клиенты", а "как устроены ваши самые крупные клиенты внутри". Ответ на этот вопрос сэкономил бы перенос данных.

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

Третье: наше же ограничение сорвало первую массовую загрузку. Для безопасности мы поставили лимит на число запросов в минуту, рассчитывая, что документы будут грузить по 30-50 штук. Пользователь загрузил разом 643 файла, и 240 из них не прошли с первого раза. Лимит под загрузку вынесли отдельно и подняли, но первое впечатление у человека было "повторяю, пока все не загрузится".

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

Пятое: нагрузочные испытания кабинета не проводились. Сервер и рабочие сервисы переданы заказчику, у нашей команды к ним доступа нет, и нагрузку проверяет ИТ-служба заказчика. Мы отвечаем за код и его поведение в заявленном окружении, а за саму инфраструктуру отвечает тот, кто ей владеет. Говорю об этом прямо, потому что вопрос "а выдержит ли" задают всегда.

Что происходит сейчас

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

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

Сопровождение при этом продолжается, просто по другой схеме. Заказчик присылает обращение, мы воспроизводим проблему у себя, правим код и отдаем ему готовое обновление с инструкцией, а ставит его ИТ-служба заказчика. Мы отвечаем за код, они за сервер. Граница проведена заранее, поэтому спора "это у вас в коде или у нас на сервере" почти не возникает.

Что можно перенести в другие промышленные проекты

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

1. Если клиент пришел с примером "хочу как у них", первым делом выясните, чем его клиенты отличаются от клиентов того, у кого он это увидел.
2. В промышленности ИНН не равно заказчик. Под одним юрлицом могут работать несколько производств, которые друг друга видеть не должны.
3. Спросите на старте, как устроены ваши самые крупные клиенты внутри. Не "кто они", а "сколько у них площадок и кто за что отвечает".
4. Не усложняйте модель заранее под гипотетический случай, но держите ее такой, чтобы перестройка не требовала переписывать все с нуля.
5. Знание ИНН не должно открывать никаких данных. Регистрация по ИНН - это удобство, а не доступ.
6. Права проверяются в каждом модуле: проекты, документы, чаты, уведомления. Одной таблицы пользователей мало.
7. Перевод сотрудника - отдельный сценарий: права прежнего производства уходят, заказы остаются за производством, отдельно выданные доступы сохраняются.
8. Тестируйте не только то, что должно работать, но и то, что должно не работать: попытку открыть чужое.
9. Проверьте каждый список и справочник на вопрос "что из этого видно без входа". Удобство регистрации легко превращается в открытую базу клиентов.
10. Лимиты ставьте не по своей фантазии о пользователе, а с запасом на перенос старых проектов. В первую неделю люди грузят архивы за годы.
11. Как только появился первый реальный случай, который не укладывается в модель, закладывайте общее решение, а не заплатку. Потом переделывать придется уже наполненную базу.
12. Не все автоматизируется. Распределение старых данных по новой структуре требует бизнес-информации, которой у системы нет.
13. Чат клиента ведите там, где клиент уже сидит. Синхронизация с Telegram лучше отдельного окна, которое никто не откроет.
14. ИИ-агент проектирует интерфейс от данных и предлагает показать все. Решение, что человеку нужно на экране, остается за вами.
15. Договоритесь заранее, кто отвечает за сервер, а кто за код. Это снимает половину споров на сопровождении.

Частые вопросы