Корпоративный ИИ глазами инженера Я - основатель https://epsilonmetrics.ru и пишу о кейсах внедрения ИИ в компаниях и о нашей no-code платформе для ИИ-агентов и аналитики данных. Без футурологии. Только практика.
СводкаГлавные показатели канала за выбранный период. Изменение — к такому же отрезку перед периодом, если за него есть статистика. Наведите на диаграмму плитки, чтобы увидеть число в каждой точке периода.
Главные числа
ПодписчикиСколько подписчиков у канала сейчас. Волна — число подписчиков в каждой точке периода. Изменение — к началу периода.14▼ 6,7 %−1 за период
ПросмотрыСколько сейчас просмотров у постов, вышедших за период. Это не просмотры за день: сколько посмотрели вчера, MAX не сообщает.24▲ 5,1 %было 24
РеакцииСколько реакций у постов, вышедших за период.0▼ 100,0 %было 2
УпоминанияСколько раз канал упомянули другие каналы: ссылки и репосты, без рекламных постов. Чем крупнее круг, тем больше упоминаний в этой точке периода.61▼ 18,8 %было 76по подписке
РепостыСколько раз другие каналы сделали репост постов этого канала (без рекламных постов). Репосты входят и в число упоминаний.28▲ 13,3 %было 25после входа
Средний охват постаСколько просмотров в среднем набирает один пост. Считаем по постам старше двух суток: у свежих просмотры ещё растут. Точки, где есть свежие посты, — пунктиром и полыми кружками: охват всех постов на сейчас, он ещё вырастет.—просмотров на пост
ERRКакая доля подписчиков видит средний пост: средний охват ÷ подписчики × 100 %. Линия — ERR в каждой точке периода, пунктир — ERR прошлого такого же периода. Точки с постами моложе двух суток — полые кружки на пунктирном конце линии.—подписчиков видят пост
Вовлечённость ERКак часто читатели реагируют на посты: реакции ÷ просмотры × 100 %. Засечка на полосе — прошлый период.—реакций на 100 просмотров
Постов в деньСколько публикаций в среднем выходит за день. Клетка — точка периода: чем темнее, тем больше постов в день.0,9▲ 215,2 %было 0,3
Доля рекламыКакая доля публикаций за период похожа на рекламу: маркировка erid, рекламные ссылки и другие признаки. Шкала — рекламная нагрузка по порогам индекса качества: до 10 % — низкая, до 25 % — умеренная, до 50 % — высокая, дальше — очень высокая. Рост доли отмечается красным.4,2 %▲ 0,8 п. п.
ДинамикаСверху — число подписчиков на конец каждой точки периода, снизу — прирост за точку: зелёный — подписчиков стало больше, красный — меньше. Над графиком прироста — самый большой прирост и самая большая убыль. Сколько подписалось и отписалось по отдельности, MAX не сообщает.
Рост аудитории
−1подписчиков за период
−1 самая большая убыль · 20 окт 2026
Оценка каналаОценка канала от 0 до 100 из пяти частей: аудитория, честность роста, рекламная нагрузка, доверие и достоверность расчёта. Полоса — сколько баллов часть набрала из своего максимума. Индекс пересчитывается каждую ночь; каналы сравниваются с похожими — той же категории и размера.
Индекс качества пока не рассчитан. Он появляется у каналов от 500 подписчиков, которые публикуют посты хотя бы раз в неделю, после недели наблюдения.
ОхватыСколько сейчас просмотров у постов, вышедших в каждой точке периода (а не просмотры за день). Подписан рекорд; точка с сегодняшним днём бледнее — день ещё идёт. Средний охват поста — по постам старше двух суток.
Просмотры и охват
24просмотров за период▲ 5,1 %
ВовлечённостьER — реакции, делённые на просмотры, в процентах — у постов каждой точки периода. Пунктир — ER за весь период. Изменение — в процентных пунктах к прошлому такому же периоду.
Вовлечённость подписчиков
—ER = реакции ÷ просмотры
За период у постов нет прочитанных реакций.
ЦитируемостьИндекс цитируемости (ИЦ) — насколько часто и какими каналами упоминают этот канал за последние 30 дней, без рекламных постов. Уровень — место среди похожих каналов. Линия — ИЦ в каждой точке периода (в неделе и месяце — средний за её дни).
Индекс цитируемости пока не рассчитан: он появится после ночного расчёта, когда канал упомянут другие каналы.
РитмСколько постов в среднем выходит в каждый час каждого дня недели, время московское: чем темнее клетка, тем больше публикаций. «Лучшее время» — часы, в которые у постов старше двух суток самый высокий средний охват.
Когда и сколько публикует
ПнВтСрЧтПтСбВс
036912151821
Лучшее время:09:0018:00часы, в которые у постов самый высокий средний охват
ФорматыИз чего состоит лента. У каждого поста один формат — по старшинству: репост, видео, фото, ссылка, текст. Полоса и проценты — доля постов формата; справа — средний охват одного поста формата (по постам старше двух суток), полоска — сравнение с самым просматриваемым форматом.
ПубликацииКаждая точка — пост за период: по горизонтали — дата выхода, по вертикали — просмотры, размер точки — реакции, цвет — формат. Так видно хиты, провалы и то, как меняется охват. У крупных каналов показаны 100 самых просматриваемых постов и равномерная выборка остальных — не больше 1 500 точек.
Каждый пост — точка
Выше — больше просмотров, крупнее — больше реакций. Нажмите на точку, чтобы открыть пост.
ВидеоФотоДругоеразмер — реакцииПриближение — кнопками «+» и «−», щипком или Ctrl + колесо мыши; приближенный график сдвигается перетаскиванием
СводкаИтоги выбранного периода: сколько вышло публикаций, сколько у них сейчас просмотров и реакций и средний охват поста. Просмотры — текущие у постов, вышедших в эти дни, а не просмотры за день. Изменение — к такому же отрезку перед периодом, если за него есть статистика.
Итоги периода
Нажмите на показатель — ниже он появится по точкам периода
Просмотрысегодня — день ещё идётТочки с постами моложе двух суток — бледные с пунктиром: их просмотры ещё растут.
РекламаКакая доля публикаций за период похожа на рекламу: маркировка erid, рекламные ссылки и другие признаки. Детектор осторожный, поэтому настоящая доля обычно выше. Шкала — рекламная нагрузка по порогам индекса качества. Ниже — средний охват рекламного и обычного поста и кого рекламирует канал (сайты, на которые ведут ссылки из рекламы).
Что работаетПосты периода с наибольшим числом просмотров. Полоса — просмотры относительно первого места. Превью — картинка поста, у поста без картинки — аватар канала. Просмотры — сколько у поста сейчас.
РитмСколько постов вышло в каждый день периода (бледные столбики) и среднее за 7 дней (линия): видно, разгоняется канал или затихает. Сегодняшний день ещё идёт, поэтому среднее для него считается по вчерашний день.
Публикации по дням
Бледные столбики — дни, линия — среднее за 7 дней: видно, разгоняется канал или затихает
Публикации за деньСреднее за 7 дней
Данные обновлены в 15:53 по Москве. Просмотры — текущие у постов, вышедших в эти дни; средний охват — по постам старше двух суток.
Как считается индекс качества
ка работа продолжится: выходят новые версии библиотек и моделей, выявляются уязвимости, меняются требования ИБ. Какие-то компоненты приходится обновлять, какие-то — заменять.
Например, однажды придётся заменить одну бесплатную библиотеку на другую. Стоимость лицензий при этом останется образцово нулевой — с этим всё прекрасно. Но работы по замене займут ненулевое время команды.
При этом системой уже пользуются сотрудники и рассчитывают, что утром она будет работать так же, как работала вчера вечером. Следить за тем, чтобы обновления системы не мешали её работе, тоже предстоит ИТ-команде.
Теперь можно себя поздравить: у компании появился ещё один внутренний ИТ-продукт. Его нужно развивать и поддерживать, документировать и помогать новым командам с ним работать.
Зато теперь одна команда поддерживает общую среду, а все остальные создают в ней агентов и не разрабатывают всё заново для каждого проекта.
2. Buy: что из этого можно купить?
Теперь у нас есть перечень необходимых возможностей и работ. С ним и изучаем КП поставщиков коммерческих платформ.
Я бы выяснила, что в этой платформе уже работает, что запланировано на туманное будущее, а что всё равно придётся делать самим. Что входит в цену? Какие компоненты поставщик обновляет и что проверяет после обновлений? Как помогает при сбоях и в какие сроки обязуется реагировать?
Отдельно смотрим, насколько проще станет создавать и запускать следующих агентов: что сможем делать самостоятельно, а где каждый раз потребуется обращаться к поставщику.
Покупка платформы добавит строку в наш бюджет. Поэтому нам максимально важно, какие строки из бюджета она позволит вычеркнуть?
Саму платформу потребуется внедрить: подключить к корпоративным системам, настроить права доступа. Эти расходы нужно прибавить к цене лицензии и поддержки.
После внедрения ИИ-агенты и доработки будут зависеть от выбранной платформы. Поэтому заранее выясняем, что удастся перенести при смене поставщика, что придётся переделать и сколько это будет стоить.
Сравниваем стоимость работы, которая исчезнет благодаря платформе, со стоимостью лицензии, внедрения и поддержки.
Более ранний запуск платформы и снижение рисков тоже учитываем.
3. Blend: а если часть купить, а часть сделать самим?
Допустим, готовая платформа соответствует значительной части требований, а недостающее проще разработать, чем строить всю среду самим.
Тогда компания покупает платформу, дополняет её собственной разработкой и отдельными open source компонентами.
Звучит тревожно: в расходах одновременно появляются и стоимость лицензии, и стоимость работы внутренней команды.
Поэтому внимательно смотрим, не разрабатываем ли мы то, за что мы уже заплатили поставщику вместе с платформой: например, управление доступом, мониторинг или конструктор агентов.
Собственные компоненты нужно связать с платформой и проверять их совместимость после обновлений.
Для уже работающих систем учитываем дополнительные расходы, которые возникнут из-за внедрения нового решения.
В Blend важны два вопроса: сколько работы покупка платформы снимет с нашей команды и сколько добавит в виде интеграции, доработки и сопровождения.
Если покупка избавит нас от разработки большей части платформы, а добавит несколько доработок — Blend целесообразен и выгоден.
А если после покупки работы у собственной команды почти не убавится, зато в бюджете появится ещё и лицензия, — вариант плохой.
Теперь можно сравнивать Build, Buy и Blend при одинаковых требованиях и на одном горизонте — например, за три–пять лет: сколько потратим, когда запустимся и какую работу в каждом варианте всё равно придётся делать внутренней ИТ-команде.
Ничего на свете лучше нету, чем ваять агентов без бюджета
«Зачем платить за вашу платформу, если есть бесплатный open source?» — это второй по популярности вопрос от наших потенциальных заказчиков.
Первый такой: «А зачем вообще что-то покупать или заказывать, если у нас в компании есть свой вайбкодер с Claude Code? Он нам всё автоматизирует». Про магию вайбкодинга в корпорации мы написали выше, сегодня об этом не будем.
А про open source короткий ответ такой: да, собрать самим можно почти всё.
Но бесплатные компоненты довольно быстро обрастают зарплатами людей, которые собирают, дорабатывают и поддерживают систему.
Покупка коммерческой платформы может снять часть этой работы и зарплат, а также сильно сократить время до запуска.
На этом короткий ответ заканчивается и начинается длинный.
У компании есть три элегантных способа потратить деньги. Назовём их, как и Gartner — Build, Buy и Blend.
1. Build: компания сама собирает платформу ИИ-агентов из open source компонентов. 2. Buy: покупает готовую коммерческую платформу ИИ-агентов. 3. Blend: покупает основу, но часть возможностей платформы реализует самостоятельно или с помощью отдельных компонентов open source.
Важно: здесь мы сговорим только о среде. Самих агентов под конкретные задачи в этой среде всё равно надо будет создавать.
Если бы мне нужно было сравнить open source и коммерческую платформу для крупной компании или банка, я бы сначала определила, что нам нужно и что уже есть.
Крупная компания редко начинает с чистого листа. На этом листе за предыдущие годы уже успели разместиться корпоративные системы, подключения к данным, права доступа и так далее. Поэтому сначала смотрим, что из этого можно использовать, а затем — решаем, чего не хватает.
1. Build: Сами собираем платформу. Например, так.
Если названия LangGraph и Kubernetes пока не вызывают у вас тёплых чувств, следующие три абзаца можно пропустить. А коллегам из ИТ, наоборот, предлагаю подумать о хорошем.
Итак, в центре, предположим, — LangGraph для логики агентов, сохранения состояния и возобновления выполнения. Для длительных процессов с участием нескольких сервисов — Temporal. LiteLLM — как единый шлюз к разным моделям. Для хранения состояния и памяти агентов — PostgreSQL, для векторного поиска — pgvector.
Для отслеживания работы агентов и оценки качества — Langfuse. Keycloak — для аутентификации и SSO. Open Policy Agent — для проверки политик доступа и ограничений на действия агентов. OpenBao — для хранения ключей и секретов.
Развернуть это можно в Kubernetes. Телеметрию собирать через OpenTelemetry, метрики — хранить в Prometheus, состояние системы показывать в Grafana.
Справедливости ради, разработчики открытого ПО от капитализма не отказывались. Одни берут деньги за дополнительные корпоративные функции, другие — за отдельные коммерческие продукты.
Так, например, компания LangChain бесплатно распространяет LangChain и LangGraph, а зарабатывает на коммерческой платформе LangSmith.
Но если бесплатных функций достаточно для выполнения наших требований — ничего не покупаем.
В общем, здесь важно не спорить с очевидным: сильная ИТ-команда всё это собрать может.
Теперь посмотрим, на что всё равно придётся закладывать бюджет.
Сначала нужно спроектировать архитектуру и связать компоненты. Затем — настроить права доступа, процессы разработки и публикации, собрать каталог агентов и доступных им инструментов.
Потом подключить корпоративные данные, организовать их обновление и разграничение доступа к ним, настроить ETL. И отдельно определить, как будем проверять качество работы агентов.
Если хотим собирать ИИ-агентов в визуальном интерфейсе no-code, понадобится и конструктор. Его тоже придётся выбрать (например, что-то похожее на всеми любимый n8n) и связать с системой.
Отдельно считаем инфраструктуру и использование моделей: оплату токенов, API, облачных или собственных вычислительных ресурсов. Эти расходы будут в любом из трёх вариантов, но могут различаться.
итик (а бывших не бывает), я вижу в этом исполнение давней своей профессиональной мечты.
То есть с ИИ дорогой и долгий индивидуальный пошив можно превратить в недорогой и быстрый пошив по меркам.
Круто это? Да! Это очень и очень круто. Сокращает это себестоимость? Да, это в десятки раз (!) сокращает себестоимость, я уж молчу про сроки.
Конечно, до промышленной системы всё равно ещё далеко, это понятно. Остаётся много работы: реальные данные, интеграции, права доступа, нагрузки, эксплуатация, резервирование, обеспечение непрерывности всё такое прочее. О том, как применяем ИИ на этих этапах, ещё поговорим, там тоже много интересных нюансов.
Но теперь хотя бы точно понятно, какую именно систему мы собираемся делать.
Что здесь, на мой взгляд, суперважно: чтобы тот, кто работает с ИИ, сам умел делать такие проекты без ИИ.
Желательно, чтобы до появления нейросетей он успел сдать хотя бы три настоящих полновесных корпоративных проекта.
Прошёл, так сказать, боевую подготовку. А если он всю жизнь зарабатывал на хлеб работой в таких проектах, - так это вообще идеальный вариант!
Таким людям ничего не нужно объяснять — они всё прекрасно знают. Скажу даже больше: сейчас у них открылось второе дыхание в профессии и наблюдается эмоциональный подъём в связи с возможностью делать классные масштабные проекты, которые ещё недавно отложили бы после первой же оценки затрат.
Если ты не разрабатывал большие проекты по автоматизации, ИИ всегда будет казаться магией и волшебством
А вот те из нас, кто разрабатывал корпоративные системы ещё на C++ и ранней Java, до изобретения слова «микросервисы», смотрят на ИИ без мистического трепета.
С ИИ мы можем гораздо быстрее делать ту работу, которую и так хорошо умеем делать.
Чтобы показать, как именно меняется разработка ПО, проще всего вспомнить метафору пошива костюмов, которой в автоматизации пользуются ещё с прошлого века:
1. Готовые коробочные продукты — это «массовый пошив». 2. Заказная разработка с нуля — это «индивидуальный пошив» (bespoke), костюм ручной работы у дорогого портного: идеально, но бесконечно долго и астрономически дорого.
Идеальным решением всегда выглядел третий режим — made-to-measure (пошив по меркам): подбираем готовые лекала, уточняем их под мерки конкретного клиента и шьём.
Но раньше без ИИ эта идея не работала. Ручная перекройка готовой базы под специфику заказчика «съедала» столько же времени и сил, сколько и разработка с нуля, и всё равно получался дорогой и долгий bespoke.
Теперь же ИИ позволяет быстро подобрать основу и перекроить её под наши требования. Если есть подходящая база, мы получаем нужный результат в разы быстрее и дешевле, чем при разработке с нуля.
Возьмём для примера классическую задачу: разработать систему финансовой проверки результатов проектов и подготовки отчётности.
Нужно сверить то, что было в изначальной закупке, что прописали в договоре и спецификациях, что закрыли актами, сколько заплатили подрядчику (данные из ERP) и сколько часов списали сотрудники (данные из таск-трекеров).
Вроде бы всё одинаково у всех. Но, конечно, нет. Миллион нюансов, деталей, внутренних регламентов и разных учётных систем.
Как здесь помогает ИИ? Подбирает подходящие «лекала», подсказывает, в каких местах нужно «снять мерки» с заказчика, и берёт на себя самую скучную часть «перекройки» кода под индивидуальные требования.
Фронтир-модели обладают «эрудицией», которая и не снилась ни одному аналитику или архитектору: они «видели» тысячи разных систем и подходов. Поэтому предложить идеальную заготовку под конкретную задачу для них— вопрос секунд, тогда как я бы потратила на поиск похожих решений дни, а то и недели.
Я расскажу про самый близкий мне этап проекта – подготовка работающего прототипа.
Если сильно упростить, мои несколько дней общения с моделью выглядят так:
1. Найди похожие системы. Разберись, как это сделано у других людей. (Выбор лекал). 2. Сопоставь их с моей постановкой задачи и покажи, что я упустила. (Снятие мерок). 3. Возьми за основу вот эту систему и запрограммируй логику под мои требования и мою архитектуру. (Перекройка лекал под мерки). 4. А теперь переделай пользовательские интерфейсы, чтобы было красиво (это моё любимое :). (Отделка). 5. И наконец — сгенерируй тестовые данные и подготовь всё к завтрашнему показу. (Примерка).
Конечно, между этими пунктами кипит много работы: проверки, уточнения и корректировки, переделки. То есть только отдыхать или думать о высоком, пока «впахивают роботы, а не человек», не получается.
Даже наоборот, мне кажется, – появляется какой-то азарт, что даже заснуть иной раз не можешь – так и тянет к ноутбуку проверить, что там ещё придумали твои ИИ-агенты, и сколько токенов осталось до сброса лимита.
Но при этом что я могу сказать: в старые времена за первые дни пресейла я успевала от силы нарисовать презентацию. Да что там говорить: бывало, что удавалось вообще только почитать переписку и провести пару осторожных установочных созвонов.
А сегодня за эти несколько дней я делаю работающий прототип огромной системы. И не отвлекаю при этом от работы ни архитекторов, ни разработчиков, ни заказчиков. К ним я приду уже с готовой демонстрацией и мы сможем предметно поговорить.
Если что-то в этом прототипе я не учла или не поняла – ничего страшного, я это быстро и почти бесплатно сделала, и я это быстро и почти бесплатно исправлю.
ля этого настраиваем интеграции и определяем источники данных. А заодно решаем вопросы доступа.
То есть мы можем купить подписку на условный ChatGPT или что-то менее западное, но модель не знает наших данных. Нужно их как-то собрать и ей передать.
Да, у поставщика могут технически готовы коннекторы и инструменты интеграции. Но решить, к каким системам подключаться, какие данные использовать и на каких условиях, всё равно должна сама компания.
В ИТ этот процесс называют ETL (Extract, Transform, Load — извлечение, преобразование, загрузка).
На складе 100 штук: сколько из них можно продать (семантика данных)
Дальше – надо разобраться, что именно эти данные означают?
Например, в системе указано, что на складе есть сто единиц товара. Но значит ли это, что мы можем пообещать клиенту сто единиц? Нет, не обязательно.
Пятьдесят из них вчера зарезервировали под другого покупателя, двадцать лежат на складе во Владивостоке, а остальные тридцать пора списать.
То же самое со скидкой. В общем прайсе может быть одна цена, а в действующем договоре с конкретным клиентом — другая.
Для того, чтобы передать такую работу системе, эти знания нужно сделать понятными для системы. Инженеры называют это термином «семантика данных».
На практике, конечно, начинать с нуля приходится не всегда. Если данные уже приведены в порядок, правила формализованы, то значительная часть основы у компании уже есть. Но мне встречаются такие компании редко.
Сколько автоматизации нам действительно нужно (целесообразность)
При этом важно подходить без фанатизма.
Конечно: если нужно просто быстрее разово готовить документы, и полученная экономия устраивает компанию — задача решена и дополнительная автоматизация не нужна, работаем просто с моделью.
А если мы обещаем сократить двухдневное согласование и работать на большом потоке, лучше сделать автоматизацию.
В экономике это называют оценкой целесообразности и ROI (окупаемости инвестиций).
Остаётся еще один вопрос — стоимость токенов и как её оптимизировать. Об этом поговорим в следующий раз.
Тонкое искусство ускорения, или «У нас уже есть ChatGPT»
В кругу руководителей и примкнувших к ним оптимистов мне часто задают такой вопрос:
«Оля, мы уже купили сотрудникам подписки на лучшие модели ИИ. Зачем нам ещё какая-то автоматизация?»
Вопрос понятный. Тем более что современные модели действительно умеют всё, что нужно в роскошной офисной жизни. Не принципиально, кто их разработал — OpenAI, Anthropic или другая компания.
Я и сама с трудом могу припомнить день, когда готовилась к встрече, разрабатывала документ или презентацию без ИИ. Это было очень давно.
Давайте посмотрим, что происходит, когда мы просто выдаём этот чудо-инструмент отдельно взятому офисному труженику?
Посмотрим на сильно упрощённом примере. Детали убрала, чтобы вы не задремали, дорогие коллеги, но смысл остался.
Пять минут на разработку КП, два дня на «пробку» из КП на согласовании
Вот наш менеджер, готовит коммерческое предложение. Раньше это занимало сорок минут: он сверял прайсы, вглядывался в остатки на складе, тяжело вздыхал и размышлял об устройстве мироздания.
Сегодня же он отправляет свои файлы в условный ChatGPT и даёт пару команд.
Нейросеть за пять минут пишет документ такой красоты и стройности, какой автор этих строк, при всём своём многолетнем опыте, добилась бы разве что ценой невероятных духовных усилий. Хотя, нет, и такой ценой не добилась бы.
Менеджер радуется. Его личная эффективность взлетела до небес. Отправляет блестящее КП на согласование юристам, финансистам и риск-менеджеру — и с чувством выполненного долга уходит пить кофе или воодушевлённо приступает к следующему КП.
Тем временем коммерческое предложение зависает на согласовании… точно так же, как и пять лет назад. На те же самые два безнадёжных дня.
Клиент, ради которого всё затевалось, никакого прогресса пока не заметил.
Зато согласующие подразделения приходят в состояние тихого бешенства, так как на их невинные головы ежечасно стала обрушиваться лавина КП, сгенерированных окрылёнными менеджерами.
А доверить ИИ ещё и согласование документов они пока ещё не готовы по причинам вполне осязаемым.
Эта идея — ещё из теории ограничений: если ускорить только одно звено в цепи и не менять остальную систему, мы получаем не ускорение, а, наоборот, увеличенную очередь на столе у несчастного юриста, финансиста или риск-менеджера (а то и у всех троих).
Что сделать, чтобы этого не было?
Ответ лишён романтики: автоматизировать весь сквозной процесс.
Например, компания может заранее установить условия, при которых КП не нужно направлять на согласование. Система будет проверять их самостоятельно по актуальным данным.
Тогда на согласование будут приходить уже не все КП подряд, а только те, с которыми система самостоятельно не сможет разобраться.
Другими словами, встроить в систему лимиты, комплаенс, внутренние регламенты и правила. Тогда система сможет учитывать нашу уникальную бизнес-специфику, а если нужно, то и отраслевые или регуляторные требования.
То есть, когда менеджер просто просит ChatGPT написать КП — модель знает, что делать. Это базовая, скажем так, предметная область, плюс-минус одинаковая для всех.
Но когда мы начинаем автоматизировать согласование этого КП с юристами, финансистами и так далее, то универсальной предметной области не хватает, и нужны специализированные правила, - внутрикорпоративные, регуляторные и даже отраслевые.
Консультанты называют это доменной спецификой.
Теперь предположим, что у нас таких заявок приходит сто или тысяча в день. Кто соберёт данные (интеграции и ETL)
Ранее мы посмотрели, что для одного предложения менеджер сам нашёл договор, выгрузил прайс, уточнил остатки и передал всё это модели.
А если таких заявок не одна, а тысяча в день? Тогда подготовка данных для модели станет отдельной большой работой. Если её будут делать менеджеры, то они только этим и будут заниматься.
Значит, системе нужно автоматически получать актуальные данные из CRM, ERP, складских систем и разных документов и таблиц.
