Новый алгоритм может уверенно выигрывать A/B‑тест и не показывать ожидаемого эффекта после запуска, если эксперимент учитывает только пользователей, но игнорирует общий ресурс. В статье разбираемся, как работают switchback‑эксперименты, почему стандартный анализ даёт ложные выводы и как корректно оценивать результаты.
Трём моделям, включая топовую облачную, дали задачу на 15 шагов. 27 запусков, ни одного полного успеха, и все три рапортовали о завершении, которого не было. В сети из 27 тысяч магазинов 26 моделей проверяют 10 млн фото в месяц на 4 vCPU. Пилот ИИ-ассистента на 100 инженерах не сдвинул ни одну метрику разработки.
Это не три случайных истории. Я прочитал 1352 внедрения ИИ в российских компаниях, от банковского антифрода до дронов над полями, и нашёл шесть закономерностей, которые повторяются от кейса к кейсу. Одна из них объясняет, почему модели в этих кейсах можно менять местами без потери результата.
Внутри: где ломаются агенты, почему один цех даёт 270 млн рублей в год, а платформа на 34 тысячи сотрудников пока не даёт ни одной цифры, и что спрашивать у вендора вместо «какая у вас модель».
Задача «поменяй у всех, кто…» обычно стоит часа подготовки: выгрузить конфигурацию, написать обработку в конфигураторе, загрузить обратно и только там увидеть, что имя реквизита не то. В статье - прогон целиком, без выгрузки: ИИ-агент внутри 1С собирает запрос по задаче, сформулированной обычными словами, сам находит в метаданных базы нужный реквизит, дважды правит запрос по ответу платформы, а мастер собирает из этого запроса внешнюю обработку .epf с полями на форме. Демо-база УТ 11.5, пять позиций номенклатуры, промпты дословно, кадры каждого шага, в конце - где границы и что осталось на руках.
Обычный день, любимый сервис и рандомная проверка: делюсь своим рабочим кейсом. Как из обычной проверки сервиса, который работал без замечаний, выросла целая задача на дедупликацию данных. Расскажу, в чём была разница между одинаковыми записями, как я искала «ту самую» среди десятков похожих и почему не стоило выбирать поваром Рафаэля только за то, что он последним заходил на кухню.
Как разобраться в неоднозначных требованиях, согласовать изменения с заказчиком и удержать проект в рамках ресурсов? Эти задачи станут темами INFOSTART A&PM EVENT 2026 — конференции для аналитиков и руководителей проектов 1С, которая пройдет 12–14 ноября в Санкт‑Петербурге.
Программа сформирована: опубликованы принятые доклады и практические активности. Практические форматы займут 70% программы, выступления с разбором проектного опыта — 30%.
В программе пять секций:
К этой статье меня подтолкнула причина донельзя прозаическая. Сижу недавно на брифинге, и прилетает жалоба: сервер отчётов работает из рук вон плохо. Сервер при этом не мой, в орбиту обслуживания он не входил, а тут пришлось вспомнить, как оно всё устроено у SQL Server Reporting Services (SSRS), вспомнить молодость, так сказать. Вспомнил. Заодно собрал то, чего мне самому когда-то не хватало, — и решил, что пора всё это выложить в одну статью.
Сервер отчётов — сервис незаметный, пока кто-нибудь из бизнеса не напишет: «а почему мне со вчерашнего дня не приходит утренняя рассылка». Сидишь, открываешь портал, видишь, что подписка вроде есть, вроде активна, а письма не уходят. Ну и как оно всегда было? Лезешь в логи, а логов нормальных нет, есть только таблица где-то внутри базы, в которую редко кто, кроме DBA, и заглядывал.
Знакомо? Если вы держите SSRS или его старшего брата Power BI Report Server, наверняка знакомо.
Вопросы, на которые SSRS обязан отвечать сам, звучат просто.
Какие рассылки упали этой ночью и по какой причине?
Какие отчёты открывают чаще всего, а какие не открывали полгода? Это обычная статистика использования отчётов, которой в портале нет.
Где сервер реально упирается в ресурсы?
Кто владелец подписки, которая ломается третью неделю подряд?
Штатными средствами ни один из этих ответов не достаётся: портал показывает список объектов, а журнал выполнения лежит таблицей в служебной базе, без графиков поверх. Ниже — как я собрал дашборд в Grafana поверх базы ReportServer и какие грабли попались по дороге.
Всё началось со странности в Google Analytics. Для регионального новостного сайта сервис неожиданно стал показывать очень большую долю посетителей с настольных компьютеров.
Это выглядело неправдоподобно: реальная аудитория новостных сайтов сегодня в основном приходит со смартфонов. Но ещё интереснее оказалось другое — значительная часть новых «читателей» якобы находилась в китайском городе Ланьчжоу.
Я решил разобраться, откуда взялись эти люди и люди ли это вообще.
Последние пару лет вокруг нас появляется огромное количество историй о том, что LLM вот-вот станут полноценными сотрудниками компаний.
Человек пишет задачу обычным языком или кивает в монитор, а искусственный интеллект понимает, что нужно сделать, сам находит нужные системы, выполняет действия, проверяет результат и двигается дальше.
Мы решили не спорить с этой идеей, а провести очередной эксперимент в нашей небольшой лаборатории. На этот раз задача звучала просто: создать процессного ассистента, который бы последовательно выполнил 2 действия –
Вайб-кодинг уже стал привычным способом разработки: человек описывает задачу обычным языком, а ИИ помогает писать и уточнять код. Но до кода обычно появляются требования, карта процесса и техническое задание. Если этот этап выполнен поверхностно, модель лишь быстрее создаст решение не той задачи.
Для работы аналитика точнее подходит термин вайб-спекинг — диалог с ИИ, в котором исходная идея постепенно превращается в спецификацию: с границами доработки, объектами конфигурации, исключениями, рисками и критериями приёмки.
Главное условие здесь — контекст. Универсальная языковая модель может хорошо оформить документ, но не обязана знать устройство конкретной версии конфигурации 1С. Поэтому полезность ответа зависит не только от промпта, но и от того, есть ли у агента сведения о метаданных и типовых механизмах системы.
В статье разберём, какие задачи можно делегировать такому помощнику и где его выводы всё равно должен проверять специалист.
В этой части нашего техно-триллера решил поговорить про календари, почту и адресные книги. Здесь, как и в мессенджерах, прямо сейчас активно разбивают Vendor Lock-in через стандартизацию открытых протоколов и антимономопольные суды. И одновременно, на наших глазах формируется новый узел вендор-лока, и стартует новая борьба, теперь за контекст для корпоративного ИИ. В 2026 году Big Tech начинает продавать бизнесу уже не просто почту и календари, а социальный и когнитивный граф, который мгновенно испаряется при любой попытке миграции. Сможет ли связка открытых протоколов JMAP + Matrix (MSC4496) обеспечить бизнесу владение собственным семантическим контекстом?
Почему одинаковые данные могут давать разные p-value? На простом примере с монетой разбираю, как правило остановки меняет частотный вывод, а затем связываю это с подглядыванием в A/B-тесты и повторными проверками значимости. Заодно становится понятнее, что именно ломается при peeking и почему проблема не в самом просмотре данных, а в том, как промежуточные результаты влияют на решение остановить эксперимент.
Агент завершил запуск, вернул корректный формат и прошёл автоматическую проверку. Почему этого всё ещё недостаточно для приёмки — и какие отдельные гейты нужны между completion и решением человека.
В одном из проектов мы развернули рабочую версию управленческой аналитики на сервере. Данные приходили из нескольких внутренних систем, часть доступа была организована через API смежной команды, а сверху уже строились витрины и дашборды. Первую версию показали руководству, получили согласование и перешли к дальнейшему развитию.
На этом месте легко поставить мысленную галочку напротив пункта «BI внедрён». Сервер работает, отчёт открывается, цифры можно фильтровать, пользователи получили ссылку. Формально результат есть.
Но через некоторое время платформа обновилась, и часть уже созданных дашбордов потребовала восстановления и переработки. Параллельно продолжали меняться источники, уточнялись показатели, появлялись новые запросы. Отчёт, который вчера был правильным, сегодня мог не обновиться, потерять связь с источником или просто перестать соответствовать процессу.
Я не считаю эту ситуацию особенностью конкретной BI-системы. В нашем случае использовалась Visiology, но похожий сценарий возможен с Power BI, DataLens, Metabase и практически любым другим продуктом. Причина обычно находится не в одной кнопке и даже не в самой платформе. Проблема в том, что дашборд воспринимают как итог внедрения, хотя на самом деле это только пользовательский интерфейс большого контура.
После публикации начинается не завершение проекта, а эксплуатация. И именно в этот момент становится видно, построили мы BI как организационный продукт или просто положили на сервер несколько красивых отчётов.
Начало в статье ERP внедрили. Что дальше?
Термины, используемые в статье
Project-DR ERP Technology Distribution — полное название технологической сборки. В дальнейшем — «технологическая сборка Project-DR ERP», версия.
Project-DR — Project Digital Replica, проектная цифровая реплика — внутренняя производственная технология и проектная среда, в которой строится и при необходимости структурно перестраивается профессиональная модель предприятия. Заказчику Project-DR как технологическая среда не передаётся.
Project Core — проектное ядро — проектный носитель специализированного ресурса, в котором хранится подробный результат его работы по конкретному проекту.
Unified Project Store — единое проектное хранилище — машиночитаемый слой Project-DR, в котором собираются принятые проекции результатов специализированных Project Core.
Enterprise-DR — Enterprise Digital Replica, цифровая реплика предприятия — эксплуатационная машиночитаемая модель конкретного предприятия, полученная из принятого состояния Project-DR. Именно Enterprise-DR передаётся заказчику.
Enterprise-DR Runtime — эксплуатационная среда Enterprise-DR — физически работающая система, в которой клиентская модель загружена в базу данных и доступна через Enterprise-DR API.
Enterprise-DR Runtime Kit — комплект, передаваемый заказчику для развёртывания и эксплуатации Enterprise-DR.
PostgreSQL — система управления базами данных, используемая в версии 2.5.1 как эталонная реализация базы Enterprise-DR. Далее — «база Enterprise-DR».
Enterprise-DR API — программный интерфейс доступа к эксплуатационной модели. Через него получают профессиональный контекст, причины решений, зависимости, сигналы и операции изменения.
Как три вопроса к заказчику про жизнь после MVP поменяли ролевую модель портала: от одной таблицы связей к RBAC + ABAC. Внутри ER‑диаграмма, SQL проверки доступа и пример на живом пользователе.
Плюс список вопросов, которые теперь задаём на каждом брифинге про доступы.
Аналитик на вебинаре поинтересовался иерархическими индексами для нормативки: дерево «документ → статья → пункт», модель спускается от корня и выбирает ветку, как человек листает оглавление. И сразу про затраты: индексация — это проход по всему корпусу.
Я сравнил такой индекс с B-деревом. Потом сел считать, и сравнение выдержало.
В B-дереве на диске узел подгоняют под блок, чтобы реже перемещать головку. Здесь блок — эффективное окно маленькой модели, а движение головки — обращение к ней.
Прикинем. Шесть актов на ~200 страниц — глубина 2. 2M токенов — глубина 3. Навигатор читает 8–12 тысяч токенов вместо всего корпуса. А само дерево в законах уже есть: главы, статьи, части, пункты. Строится регекспами по нумерации, без модели. Затраты один раз и только за краткое описание внутренних узлов.
Навигатору остаётся выбрать одну из пятидесяти веток по короткому описанию. Это ближе к классификации, чем к рассуждению. В зале спросили, справится ли с этим модель на 1,5–3 млрд параметров. Интрига.
В статье разберём, какие есть способы получать точные ответы по юридически значимой документации.
От работающей ERP к цифровой реплике и вычислимой модели предприятия
Когда-то, много лет назад, значительная часть моих публикаций на инфоплощадках так или иначе вращалась вокруг довольно простого вопроса: «Купили ERP — что дальше?» Предприятие приобрело большую систему, руководство ждёт от неё результата, проектная команда собрана, консультанты пришли, пользователи продолжают работать — и в этот момент выясняется, что сама покупка программного продукта практически ничего не решает. Нужно понять, что именно внедрять, как организовать проект, как обследовать предприятие, где заканчивается методология и начинается автоматизация, кто принимает решения и каким образом всё это в конечном счёте должно превратиться в работающую систему.
С тех публикаций прошло много лет. За это время через нашу практику прошло больше сотни проектов — очень разных по масштабу, состоянию предприятия, отрасли, составу команды и исходной культуре управления. Были действительно удачные проекты, после которых оставалось ощущение серьёзного профессионального продвижения. Были проекты, где отдельное решение становилось настоящим прорывом и потом переходило в следующие внедрения. Были и совершенно другие истории, когда месяцами двигаешься, проводишь совещания, выпускаешь документы, закрываешь этапы, а потом честно признаёшь самому себе, что по существу находишься примерно в том же месте, с которого начинал.
Это не научная статистическая выборка, и я не пытаюсь её так называть. Но когда за спиной уже не несколько кейсов, а больше сотни проектов, постепенно начинаешь отличать случайность конкретного внедрения от проблемы, которая повторяется при разных заказчиках, командах и информационных системах. Если один и тот же вопрос возвращается снова и снова, значит, дело, скорее всего, уже не в особенностях отдельного предприятия. Возможно, чего-то не хватает в самой технологии проекта.
В одном из проектов мне нужно было развивать управленческую аналитику в крупной образовательной организации. Данные уже были: учебные процессы, финансовые показатели, поступления и другие направления хранились во внутренних системах. Руководству требовались не очередные Excel-файлы, а единый BI-контур с дашбордами, детализацией и регулярным обновлением.
На тот момент я уже работал с Power BI и DataLens, а рабочую версию управленческой аналитики мы развернули на сервере в Visiology. Прототип показали руководству и получили согласование на дальнейшее развитие. То есть на уровне первой демонстрации всё получилось: данные загрузились, дашборды открылись, показатели можно было обсуждать уже не на словах.
Если смотреть только на этот момент, систему можно считать выбранной успешно.
…а не по пинку от внешних расследователей, как это было последние разы (в эпизодах с роем агентов на немецкой вики и со взломом RubyGems). Заодно OpenAI раскрыли шесть новых примеров странного поведения своих моделей, разберем в этом материале кратко самое интересное.
Заказчик — страховая компания, которая имеет ключевое значение для устойчивости российской экономики. Среди ее клиентов финансовые организации, промышленные предприятия, транспортные компании, а также исполнители крупных инфраструктурных проектов.
Проект решил три задачи одновременно: гарантировал выполнение требований законодательства по импортозамещению без потери функциональности, сохранил независимость от конкретного вендора и обеспечил официальную поддержку с SLA. Работа с Хоулмонт позволила реализовать все это и не останавливать развитие проекта даже тогда, когда Camunda сменила бизнес-модель.
Команда исключила риск потери компетенций: специалисты быстро освоили весь стек используемых технологий, новые сотрудники быстро включаются в работу. Это касается как BPM-движка, так и платформы, на которой реализованы функциональные и сервисные модули системы.
Модульная архитектура ускорила отклик интерфейса и упростила дальнейшее развитие системы.