Вопросы и ответы: про разработку, деньги и поддержку

С разбора задачи: что за продукт, кто им пользуется, какие процессы он должен закрывать и что считается результатом. Дальше — аудит текущего состояния (если что-то уже есть), состав первой версии, срок и смета. Только после этого начинается разработка: так смета опирается на понятный объём, а не на предположения.

Нет. Мы умеем собирать требования сами: проводим интервью с вашей командой, описываем сценарии, показываем прототипы и согласуем объём. Если ТЗ уже есть — разберём его, отметим противоречия и предложим, что стоит уточнить до старта, чтобы это не всплыло в середине проекта.

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

Работаем итерациями: каждые 1–2 недели вы видите работающую версию на тестовом стенде, а не отчёт о занятости. Демонстрации короткие и по делу: что сделано, что можно потрогать, какие вопросы нужно решить с вашей стороны.

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

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

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

Нижняя граница опубликованных пакетов — от 149 000 ₽: это проект малого масштаба с фиксированным объёмом. Дальше стоимость определяется четырьмя вещами: числом сценариев, сложностью интеграций (1С, платежи, логистика, маркетплейсы), требованиями к нагрузке и надёжности и объёмом переноса данных. Точную смету считаем после разбора задачи и фиксируем в договоре.

Смета собирается по этапам с перечнем работ и результатом каждого этапа. После согласования объём не меняется молча: если появляется новая задача или выясняется ограничение, мы показываем, как это влияет на срок и стоимость, и только потом берём в работу. Скрытых доработок «по факту часов» у нас нет.

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

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

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

Да, когда объём понятен: пакеты, аудиты, отдельные модули и этапы считаем фиксированно. Для исследовательских задач, где неизвестен объём (например, разбор чужого легаси-кода), фиксируем стоимость этапа аудита, а разработку оцениваем после него.

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

Мы гарантируем не «позиции в поиске», а качество работы: соответствие согласованному объёму, работоспособность на приёмке, отсутствие критичных дефектов и исправление ошибок, допущенных нами, за наш счёт. После запуска действует гарантийный период поддержки, его длительность фиксируется в договоре.

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

Да. Вы забираете результат выполненного и оплаченного этапа вместе с кодом и документацией, а мы передаём доступы и наработки. Мы не удерживаем проект и не берём плату за «передачу».

Да, подписываем соглашение о конфиденциальности до передачи доступов и материалов. Если у вас есть свой шаблон NDA — рассмотрим его; если нет, предложим свой. Отдельно оговариваем, что можно упоминать в портфолио, а что нельзя.

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

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

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

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

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

Да: автоматические бэкапы по расписанию с проверкой восстановления, а не «наличие файла». Для критичных систем настраиваем репликацию и хранение копий в другом месте. Регламент восстановления и время простоя фиксируются в договоре поддержки.

Да. Смотрим типовые уязвимости (инъекции, доступ к чужим данным, слабая аутентификация, открытые файлы и админки), состояние зависимостей и версий, логирование и права. На выходе — отчёт с приоритетами: что закрывать немедленно, что можно планировать.

Первые недели — стабилизация: следим за ошибками, метриками и обратной связью пользователей, исправляем найденное. Дальше проект переходит на поддержку: обновления, мониторинг, доработки по приоритетам. Опубликованный формат поддержки у нас — сопровождение по SLA, а для пакетов малого бизнеса — 90 дней поддержки после запуска.

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

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

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

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

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

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

Мы делаем для этого отдельную работу: собираем карту всех URL из базы, sitemap и логов, сохраняем совпадающие адреса и закрываем остальные 301-редиректами, переносим метаданные и микроразметку. После переключения следим за ошибками 404/500, индексацией и позициями.

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

Да, и часто это лучший вариант: выносим на Laravel отдельный модуль или участок, связываем его с остальной системой через API и живём дальше. Так снижается риск и появляется первый современный участок, на который можно опираться.

Аудит и карта системы — 1–3 недели, проектирование и подготовка данных — 2–3 недели, перенос и разработка — от 8 недель, переключение и стабилизация — 2–4 недели. Разброс определяется объёмом кода и качеством данных, а не размером интерфейса: на аудите мы называем срок конкретно для вашего случая.

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

Платный трафик даёт обращения сразу после запуска кампаний, обычно в первые дни. Органика накапливается: первые измеримые сдвиги в Search Console — через 4–8 недель, первые заявки из поиска — на 2–3-й месяц, заметный рост — на 4–6-й. Мы говорим об этом до договора, чтобы ожидания совпадали с реальностью.

Нет, и никто не даёт: позиции определяет алгоритм. Мы гарантируем объём и качество работ, прозрачную отчётность и KPI по видимости и трафику, зафиксированные в договоре. Если по данным аудита роста не будет — скажем об этом до начала работ.

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

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

Вам. Кабинеты, счётчики, аккаунты аналитики, контент, семантические ядра и отчёты оформлены на вас. Мы работаем внутри ваших аккаунтов, поэтому смена подрядчика не обнуляет историю и накопленные данные.

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

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

Пилот — быстрая модель на ваших исторических данных за 2–4 недели. Его задача — проверить, есть ли в задаче сигнал и сколько он стоит, до вложений в продакшен. На выходе вы получаете оценку эффекта и решение: идём дальше или нет.

Сравнением с текущим правилом на том же периоде (baseline), а затем — контрольной группой в продакшене. Метрика переводится в деньги: стоимость ошибки, сэкономленные часы, снижение оттока, сокращение потерь. Показываем формулу расчёта и допущения, чтобы цифру можно было перепроверить.

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

Она живёт: данные меняются, качество постепенно падает. Поэтому сразу настраиваем мониторинг дрейфа и метрик, алерты, переобучение по расписанию и триггерам и откат на предыдущую версию. Это часть работы, а не «отдельная услуга потом».

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

Аудит процессов и техническое задание — от 150 000 ₽. Внедрение отдельного блока или доработка существующей системы — от 500 000 ₽. Проект под ключ с воронками, задачами, телефонией и интеграцией с 1С — от 1 200 000 ₽. Поддержка — от 60 000 ₽ в месяц. Точная смета считается после аудита, когда понятен объём интеграций и миграции.

Аудит занимает 2–3 недели, проектирование — 2–4 недели. Первая рабочая версия с клиентской базой, воронкой и задачами появляется через 2–4 недели после старта разработки, полный контур с интеграциями — через 8–16 недель. Срок зависит от числа ролей, каналов заявок и сложности обмена с учётной системой.

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

Аудит и предпроект — от 250 000 ₽. Пилотный контур из двух-трёх ключевых модулей — от 900 000 ₽. Проект под ключ с интеграциями, миграцией данных и обучением — от 2 500 000 ₽. Поддержка работающего контура — от 90 000 ₽ в месяц. Итоговая смета зависит от числа модулей, подразделений и сложности обмена с 1С.

Аудит и предпроект занимают 3–6 недель, технический проект — ещё 3–5 недель. Пилотный контур выходит в работу через 3–5 месяцев после старта разработки. Полное тиражирование на подразделения зависит от их числа и готовности данных: обычно это следующий этап проекта, а не один общий запуск.

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

Стоимость зависит от числа площадок, схем работы и состояния учёта. Аудит и стратегия — от 150 000 ₽, подключение одной площадки — от 400 000 ₽, мультиканальный контур с сайтом и складом — от 900 000 ₽. Поддержка — от 60 000 ₽ в месяц. Точную смету даём после аудита процессов и интеграций.

Подключаем Ozon, Wildberries, Яндекс Маркет и Мегамаркет по их API. Если вы продаёте на другой площадке с открытым программным интерфейсом, интеграцию разрабатываем отдельно: обмен строится по тем же принципам — каталог, цены, остатки, заказы и отчётность. Перед стартом проверяем доступные методы и ограничения по частоте запросов.

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

Стоимость зависит от площади склада, числа операций в смену и состава интеграций. Аудит склада — от 150 000 ₽, внедрение на одной площадке — от 700 000 ₽, сеть складов с распределительным центром — от 1 500 000 ₽. Поддержка — от 70 000 ₽ в месяц. Смету даём после обследования.

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

Нужны терминалы сбора данных, сканеры штрихкодов и принтеры этикеток. Часть имеющегося оборудования обычно удаётся сохранить: мы проверяем совместимость и состояние техники до начала работ. Wi-Fi на складе проектируем под зоны, где работают терминалы, чтобы сканирование не зависало в дальних рядах.

Стоимость зависит от числа каналов, объёма обращений и глубины интеграций. Аудит сервиса начинается от 250 000 ₽, первая рабочая итерация с единым окном, регламентами и базой знаний — от 500 000 ₽, полный контур со всеми каналами, сервисными процессами и аналитикой — от 1 200 000 ₽. Точную смету даём после аудита.

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

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

Учётная система отвечает за остатки, документы и себестоимость, а PIM — за описание товара: атрибуты, контент, медиа, SEO-поля и правила публикации в каналы. Мы не заменяем 1С, а связываем системы обменом: номенклатура, цены и остатки приходят из учёта, а карточки и выгрузки живут в PIM.

Аудит номенклатуры и справочников начинается от 150 000 ₽. Внедрение для одного канала — от 500 000 ₽, мультиканальный контур с интеграциями с 1С, маркетплейсами и печатным каталогом — от 1 100 000 ₽. Поддержка — от 60 000 ₽ в месяц. Смета зависит от объёма справочника и числа каналов.

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

Учётная система ведёт финансы, документы и себестоимость, WMS — операции внутри склада: приёмку, размещение, отбор и упаковку. OMS управляет заказом между каналами и складом: принимает заказы, резервирует товар, маршрутизирует, передаёт в доставку и ведёт статусы для покупателя. Мы связываем все три контура обменом данными.

Аудит процессов начинается от 150 000 ₽. OMS для одного канала — от 450 000 ₽, омниканальный контур с интеграциями с 1С, WMS, маркетплейсами и службами доставки — от 1 200 000 ₽. Поддержка — от 60 000 ₽ в месяц. Точная смета считается после аудита каналов и складов.

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

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

Аудит учёта и регламентов — от 200 000 ₽. Базовый контур с заявками на оплату, платёжным календарём и бюджетами — от 600 000 ₽. Контур управленческого учёта с ДДС, P&L и интеграциями по нескольким юрлицам — от 1 300 000 ₽. Поддержка — от 70 000 ₽ в месяц. Точную смету даём после аудита, когда понятен объём справочников и интеграций.

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

Отчёты в 1С работают с данными одной учётной системы и рассчитаны на операционные задачи. Хранилище собирает данные из нескольких источников: 1С, CRM, сайта, маркетплейсов, и позволяет считать сквозные показатели с историей и детализацией. При этом 1С остаётся системой учёта, а аналитика строится поверх неё.

Аудит данных и метрик — от 150 000 ₽. Дашборд по одному направлению с загрузкой из одного или двух источников — от 400 000 ₽. Хранилище данных с набором дашбордов и конструктором отчётов — от 1 000 000 ₽. Поддержка — от 50 000 ₽ в месяц. Точная смета считается после аудита источников и показателей.

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

Ориентируемся на требования клиентов и профиль нагрузки. Для тысяч небольших аккаунтов и быстрого запуска подходит общая база с tenant_id и обязательным tenant-контекстом. Когда нужны раздельные права, бэкапы и быстрое удаление по клиенту, берём схему на тенанта. Отдельная база или кластер оправдана для крупных корпоративных заказчиков с требованиями к производительности и локализации данных.

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

Комбинируем три меры: квоты на тенанта, разделение ресурсов и наблюдаемость. Квоты ограничивают частоту запросов, параллельные фоновые задачи и объём выгрузок. Тяжёлые или крупные тенанты выносятся в отдельные очереди, воркеры и при необходимости на отдельный шард. Метрики разрезаются по tenant_id, чтобы деградация была видна до жалоб клиентов.

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

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

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

Она делает копии приложения взаимозаменяемыми. Сессии, кэш и блокировки живут в Redis, файлы — в объектном хранилище, поэтому балансировщику не нужны sticky-сессии, а оркестратор может поднимать и гасить реплики в любой момент. Без этого шага автоскейлинг либо не работает, либо ломает пользовательские сценарии при переключении.

Правильный кэш имеет измеримый hit ratio и предсказуемую инвалидацию: ключи версионируются или группируются тегами, а не сбрасываются целиком по расписанию. Мы отдельно закрываем лавину при прогреве горячего ключа — блокировкой на время пересчёта и jitter в TTL, иначе одновременный сброс кэша обрушивает базу запросами.

Нет, это только один рубеж. Фильтр в коде легко забыть в новом отчёте, экспорте или фоновой задаче, и ошибка не проявится на тестах с одним тенантом. Поэтому мы дублируем правило внутри СУБД политиками row-level security, включёнными принудительно, и дополнительно запрещаем сырые запросы вне слоя доступа к данным.

Контекст тенанта устанавливается в начале транзакции и сбрасывается при её завершении, поэтому соединение из пула не переносит чужой контекст в следующий запрос. Роль приложения не должна иметь права обходить политики и не должна владеть таблицами. Если соединения кэшируются на уровне воркеров, контекст задаётся заново для каждой единицы работы.

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

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

Зависит от модели монетизации и юрисдикции. Если вам нужны простые тарифы, оплата картой и нет требований к закрывающим документам по российским правилам, готовая платформа дешевле и быстрее. Собственный биллинг нужен, когда есть постоплата, счета и акты, интеграция с 1С, сложный usage-based биллинг или требования к хранению данных внутри вашего контура. Часто оптимален гибрид: платежи через провайдера, логика тарифов и начислений — у вас.

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

Запускается сценарий dunning: повторные попытки по расписанию, уведомления клиенту и льготный период, в течение которого доступ сохраняется. Если оплата так и не поступила, доступ ограничивается по заранее определённым правилам, а подписка переводится в статус просроченной — без ручного вмешательства.

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

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

Подписка переходит в past_due, и запускается сценарий dunning: повторные попытки списания по расписанию, уведомления клиенту и льготный период, в течение которого доступ сохраняется. Если оплата так и не поступила, доступ ограничивается по заранее описанным правилам, а подписка переводится в cancelled с сохранением данных для последующей реактивации.

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

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

SSO передаёт аутентификацию провайдеру идентичности клиента: вход идёт по OAuth 2.0 или SAML 2.0, а ваш сервис получает подтверждённый профиль и права. Для корпоративного заказчика это означает единый вход и мгновенный отзыв доступа при увольнении сотрудника. Обычные пароли в SaaS-продукте остаются как резервный способ входа — например, для небольших команд без своего провайдера.

Интерфейс — это лишь один из клиентов API. Скрытая кнопка не мешает отправить запрос напрямую, поэтому единственная надёжная точка проверки — сервер. Мы проверяем права на уровне эндпоинта, а в мультитенантной базе дополнительно включаем RLS, чтобы запрос без фильтра по арендатору физически не мог вернуть чужие строки.

Требования пересекаются в главном: нужно знать, какие персональные данные хранятся, где именно, кто имеет к ним доступ и как долго они живут. Мы ведём реестр данных, ограничиваем доступ по ролям, шифруем чувствительные поля и реализуем удаление и выгрузку по запросу субъекта. Различия касаются локализации данных и сроков уведомления об инциденте — они фиксируются в политиках и в плане реагирования.

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

Стоимость зависит от числа точек, кассовых мест и объёма интеграций. Контур для одного магазина с товароучётом, кассой и лояльностью начинается от 500 000 ₽, сеть из нескольких точек с обменом с 1С и маркетплейсами — от 1 200 000 ₽. Точную смету даём после аудита процессов.

Да. Мы подключаем популярные модели касс и POS-терминалов, настраиваем обмен продажами, возвратами и чеками с товароучётом и 1С. Сверка с ОФД, закрытие смены и выгрузка документов происходят автоматически, без ручного переноса.

Да, мы настраиваем приёмку, продажу и вывод из оборота маркированных товаров через ГИС МТ, а для алкоголя — учёт в ЕГАИС. Кассир работает в одном окне, а расхождения по кодам маркировки видит товаровед, а не выясняет постфактум при проверке.

Стоимость зависит от размера каталога, числа интеграций и требований к нагрузке. Магазин среднего размера с оплатой, доставкой и обменом с 1С начинается от 800 000 ₽, highload-проект с маркетплейсами и личным кабинетом — от 1 500 000 ₽. Смету считаем после аудита.

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

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

Стоимость определяется числом переделов, участков и объёмом интеграции с учётной системой. Внедрение планирования и цехового учёта для одного производственного участка начинается от 1 000 000 ₽, комплексный проект с себестоимостью и MES — от 2 500 000 ₽. Смету готовим после аудита процессов.

Да, это наш базовый сценарий. Мы настраиваем двусторонний обмен: заказы на производство, спецификации, выпуск продукции, списание материалов и документы. Обмен может идти по расписанию или в реальном времени через HTTP-сервисы, с журналом ошибок и повторной отправкой.

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

Стоимость зависит от объёма интеграций и сложности ценообразования. Личный кабинет дилера с обменом с 1С и базовой CRM начинается от 900 000 ₽, полноценный B2B-портал с каталогом, лимитами и документооборотом — от 1 800 000 ₽. Точную смету мы даём после аудита процессов.

Да. Мы работаем с типовыми и доработанными конфигурациями 1С:УТ, 1С:КА и 1С:ERP. Обмен настраивается по HTTP-сервисам или через промежуточный слой: остатки, цены, номенклатура, заказы и документы синхронизируются по расписанию или в реальном времени.

Аудит и проектирование занимают 3–5 недель, разработка с интеграциями — от 6 до 12 недель в зависимости от объёма. Первые сценарии, например заказ из кабинета с актуальными остатками, запускаем до конца первого месяца.

Стоимость зависит от числа постов, складов и объёма интеграций. Система для одного автосервиса с записью, заказ-нарядами и складом начинается от 700 000 ₽, контур для дилерского центра с CRM, trade-in и подбором по VIN — от 1 600 000 ₽. Точную смету даём после аудита.

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

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

Стоимость зависит от числа площадок, сложности воронок и объёма интеграций. CRM с базой объектов и подключением ЦИАН и Авито начинается от 900 000 ₽, контур с Домклик, электронной регистрацией и мобильным приложением агента — от 1 800 000 ₽. Точную смету мы даём после аудита процессов.

Мы формируем фид по требованиям каждой площадки и настраиваем обмен так, чтобы публикация шла из карточки объекта. При смене цены, статуса или бронировании данные обновляются автоматически, а заявки с площадок возвращаются в CRM с указанием источника.

Стоимость определяется числом кабинетов, специальностей и интеграций. Расписание с онлайн-записью и электронной картой начинается от 1 200 000 ₽, контур с лабораторным обменом, ГИС МТ и телемедициной — от 2 500 000 ₽. Точную смету мы даём после аудита процессов клиники.

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

Стоимость зависит от числа каналов и объёма интеграций. Каталог с матрицей SKU и подключением одной площадки начинается от 800 000 ₽, контур с оптовым кабинетом, несколькими маркетплейсами и аналитикой коллекций — от 1 700 000 ₽. Точную смету мы даём после аудита процессов.

Мы делаем склад источником правды и подключаем площадки через обмен: остатки и цены уходят на Wildberries, Ozon и Яндекс Маркет, а заказы возвращаются в общую систему обработки. Дополнительно настраиваются правила резерва и буферов, чтобы избежать отмен из-за гонки заказов.

Стоимость зависит от числа модулей, материалов и правил расчёта. Конфигуратор для одной товарной линейки с расчётом цены и заявкой в CRM начинается от 700 000 ₽, решение с раскроем, спецификациями и интеграцией с 1С — от 1 600 000 ₽. Точную смету мы даём после аудита процессов.

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

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

Стоимость зависит от объёма номенклатуры, числа складов и набора интеграций. Партионный учёт с кабинетом клиента HoReCa начинается от 1 000 000 ₽, контур с ВетИС, ГИС МТ, весовым оборудованием и логистикой — от 2 200 000 ₽. Точную смету мы даём после аудита процессов.

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

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

Да. Мы загружаем сметы из Excel и XML-выгрузок, ведём журналы работ и фактические объёмы, а затем формируем КС-2, КС-3 и реестры по объекту. Формы выгрузок согласуем на этапе прототипа, чтобы документы совпадали с требованиями вашего заказчика.

Через мобильное приложение или веб-форму: он выбирает позицию из сметы или номенклатуры, указывает объём, срок и прикладывает фото. Заявка уходит по маршруту согласования в снабжение, а статус виден и прорабу, и снабженцу.

Да. В системе ведётся учёт по каждой единице техники: моточасы, топливо, ТО и ремонты, закрепление за объектом. Данные ГЛОНАСС можно подтягивать в систему, чтобы фактические пробеги и наработка сверялись с путевыми листами.

Да. Мы настраиваем приёмку по кодам маркировки, выбытие на кассе, перемещение между точками и возвраты, а также обмен сведениями с ГИС МТ. В системе ведётся журнал отправленных документов с обработкой ошибок и повторной отправкой.

Учёт ведётся по сериям и партиям, поэтому срок годности привязан к конкретному остатку, а не к номенклатуре в целом. Система предупреждает о партиях с истекающим сроком, подсказывает порядок отпуска и блокирует продажу просроченного товара.

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

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

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

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

Мы проектируем систему с учётом требований 152-ФЗ: разграничение прав по ролям, журналирование действий сотрудников, шифрование каналов передачи, хранение согласий и контроль сроков хранения данных. Отдельно описываем регламент доступа к персональным данным в технической документации.

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

Мы подключаем платёжные шлюзы и эквайринг через REST API и настраиваем регулярные платежи, возвраты и автоматические сверки реестров с учётной системой. Конкретный перечень провайдеров согласуем на этапе проектирования.

Первая работающая версия с ключевым сценарием, оплатой и аналитикой обычно занимает от 4 до 8 недель после согласования объёма. Точный срок зависит от количества интеграций и сложности бизнес-логики; прототип с оценкой мы показываем в первые три недели.

Ориентиры: до 5 серверов с реакцией в рабочие часы — от 45 000 ₽ в месяц; до 20 серверов с дежурством 24/7 и реакцией до 30 минут — от 95 000 ₽; отказоустойчивые конфигурации с реакцией до 15 минут и выделенным инженером — от 180 000 ₽. Итоговая стоимость зависит от числа сервисов, требуемого времени реакции и объёма плановых работ. Точную цифру даём после аудита — он занимает 1–2 недели и оплачивается отдельно.

Не обязательно. Услуга не требует миграции: мы подключаемся к текущей инфраструктуре, инвентаризируем её и начинаем управлять. Если по итогам аудита видим, что часть workloads выгоднее или надёжнее разместить иначе, предлагаем это отдельным планом — решение всегда за вами. Работаем и с одним облаком, и с гибридными схемами, и с собственными серверами.

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

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

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

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

Ориентиры: до 10 сервисов с реакцией в рабочие часы — от 55 000 ₽ в месяц; до 30 сервисов с дежурством 24/7 и реакцией до 30 минут — от 120 000 ₽; расширенное покрытие с требованиями регуляторов и реакцией до 15 минут — от 220 000 ₽. Стоимость зависит от количества источников событий, объёма логов и требуемого режима реакции. Пентест и полный аудит защищённости считаются отдельно.

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

Ориентиры: стабильное приложение с исправлением ошибок и обновлениями в рабочие часы — от 40 000 ₽ в месяц; продукт, который активно развивается, с 20 часами доработок и мониторингом ошибок — от 90 000 ₽; системы с высокой ценой простоя, дежурством 24/7 и выделенным инженером — от 180 000 ₽. Итоговая цена зависит от состояния кода и объёма доработок. Для legacy-систем стоимость определяется после аудита.

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

Обращение всё равно принимается: сначала оцениваем срочность и последствия. Если правка не может ждать, выполняем её во внеочередном порядке, а часы списываются из следующего месяца или оплачиваются отдельно — по договорённости. Мы не оставляем критичную проблему до следующего расчётного периода только потому, что закончились часы.

На пакете «Критичный» — до 30 минут круглосуточно, на «Бизнес» — до 1 часа, на «Базовом» — в рабочие часы. Реакция означает начало диагностики, а не мгновенное исправление: время до устранения зависит от причины. Для типовых сбоев у нас есть регламенты восстановления, для новых — диагностика начинается сразу, и вы получаете промежуточный статус.

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

Точность закономерно падает с горизонтом. Для недельного горизонта достижим WAPE порядка 8–12%, для месячного — 15–20%, для квартального прогноза метрика становится слишком грубой для операционных решений, но остаётся пригодной для бюджетирования. Мы всегда указываем горизонт вместе с метрикой, чтобы цифра не использовалась не по назначению.

Выбросы не удаляются автоматически: часть из них — реальные события, которые нужно уметь предсказывать. Мы разделяем их на объяснимые (промо, праздники, крупная сделка) и необъяснимые. Объяснимые становятся признаками модели, необъяснимые исключаются из обучения, но остаются в истории для контроля. Такой подход не даёт модели «размазать» реальный пик по соседним периодам.

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

Три основных приёма: учитывать сезонность и расписание (день недели, час, праздники), группировать связанные события в один инцидент вместо десятка отдельных алертов и требовать подтверждения аномалии на нескольких уровнях — например, отклонение метрики точки при отклонении регионального агрегата. На практике это снижает шум в 5–10 раз без потери полноты обнаружения.

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

Практический минимум — 100–150 примеров на класс, а для классов с высокой вариативностью формулировок до 300–500. Если классов немного и они хорошо разделяются, качественная модель получается уже на таком объёме. Разметка ведётся итеративно: сначала небольшая выборка, затем модель показывает спорные случаи, и размечается именно то, что действительно влияет на качество.

Для чернового прототипа — да, large language model по инструкции справится с классификацией на несколько классов без обучения. Ограничения другие: стоимость запроса на каждое обращение, задержка ответа, нестабильность формата и сложность воспроизводимости результата. Если обращений десятки тысяч в месяц, дообученная компактная модель или классический алгоритм на признаках окажутся экономичнее на порядок.

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

При стабильных условиях съёмки и качественной разметке реально достичь обнаружения 95–99% дефектов при доле ложных срабатываний в пределах 1–3%. Точность зависит не от архитектуры модели, а от условий: контрастности дефекта относительно фона, освещения и разрешения камеры. Если дефект размером 0,1 мм нужно различать на детали метр на метр, вопрос решается оптикой, а не нейросетью.

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

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

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

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

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

REST API описывает методы для программ, MCP-сервер — операции для языковой модели: у каждого инструмента есть семантическое описание, схема параметров и правила использования, понятные модели. Дополнительно протокол умеет передавать не только инструменты, но и ресурсы — например, содержимое документа, — а также готовые подсказки. Технически MCP-сервер может внутри обращаться к вашему REST API, добавляя слой контроля и описания.

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

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

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

Для настройки формата и стиля достаточно 500–2000 качественных примеров. Для освоения узкой терминологии — от двух-трёх тысяч. Ключевой фактор не объём, а однородность и правильность разметки: тысяча согласованных примеров даст больше, чем десять тысяч противоречивых. Если данных мало, начинаем с few-shot и накапливаем примеры из реальной эксплуатации.

Зависит от размера модели и требований к задержке. Модель на 7–8 миллиардов параметров в 4-битной квантизации работает на одной видеокарте с 16 ГБ памяти и обслуживает десятки одновременных запросов при батчинге. Модели на 70 миллиардов требуют нескольких карт или серверных ускорителей. Для пакетной обработки без требований к задержке подходит и CPU-инференс, но пропускная способность будет в разы ниже.

Для типового запроса с контекстом в 2–3 тысячи токенов и ответом на 500 токенов цена на облачных моделях среднего размера составляет доли рубля. Точная величина зависит от выбранной модели, длины контекста и объёма выходного текста. Мы всегда считаем стоимость на реальном профиле нагрузки: средний запрос, тяжёлый запрос и пиковый период, — потому что бюджет определяет пик, а не среднее.

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

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

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

Для модели на 7–8 миллиардов параметров в квантизованном виде достаточно сервера с одной видеокартой на 16–24 ГБ памяти. Индекс на несколько сотен тысяч фрагментов размещается на обычном сервере с 32 ГБ оперативной памяти. Для одновременной работы десятков пользователей может потребоваться вторая карта или более производительный ускоритель. Точные требования определяются после замера нагрузки на пилотном стенде.

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

На типовом потоке поддержки ассистент закрывает 60–80% обращений первой линии: статус заказа, условия доставки, работа сервиса, типовые неисправности, запись на обслуживание. Точная доля зависит от однородности вопросов и от того, есть ли у ассистента доступ к данным через API. Мы считаем этот показатель на контрольном наборе до разработки, а не обещаем заранее.

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

Он не придумывает. Если поиск не находит фрагментов выше порога уверенности, ассистент сообщает об этом и предлагает эскалацию: передаёт диалог оператору вместе с историей и собранными данными. Все вопросы без ответа попадают в отчёт — это готовый список тем для новых статей базы знаний.

Тогда проект начинается с выбора системы под ваш процесс: для поддержки внешних клиентов обычно подходят Usedesk или Bitrix24, для внутренней ИТ-поддержки — Jira Service Management. Мы помогаем сравнить варианты по стоимости лицензий, гибкости правил и открытости API, а затем настраиваем маршрутизацию уже внутри выбранной системы, чтобы не создавать ещё один остров данных.

На типовом потоке поддержки модель определяет тему с точностью 85–92% на десяти-пятнадцати категориях, и этот показатель мы проверяем на вашей истории обращений до внедрения. Важнее точности — поведение при неуверенности: если модель не набирает порог по двум-трём темам, заявка уходит в общую очередь с пометкой, а не назначается наугад специалисту.

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

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

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

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

На записях телефонного качества WER обычно составляет от 8% до 20% до настройки словарей и снижается до 5–12% после их дополнения терминами и названиями продуктов. Мы всегда замеряем этот показатель на вашей выборке до внедрения: если связи плохие, а в разговорах много специфических артикулов, сначала обсуждаем, какие правила вообще имеет смысл проверять автоматически.

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

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

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