Искусственный интеллект уже умеет за считанные минуты собирать дашборды, которые выглядят вполне профессионально. Проблема в том, что убедительный интерфейс легко маскирует слабую постановку задачи и сомнительные выводы. В этой статье — эксперимент с тремя промптами для Claude Design и разбор того, где заканчиваются возможности модели и начинается работа аналитика.
Запрос на дашборд часто начинается со списка показателей и заканчивается красивым отчётом, по которому непонятно, что делать дальше. На примере BI-дашборда для сравнения подразделений разбираю, как перейти от пожеланий к конкретному решению, проверить сопоставимость данных и построить структуру отчёта от отклонения к деталям.
Ниже не попытка восстановить всю работу над проектом по дням, а структура подхода, к которой я пришёл на практике.
BI снова хоронят: подключаем LLM к хранилищу и аналитики больше не нужны, деньги тратить на лицензии не нужно. По крайней мере, так выглядит обещание.
На практике дата-агент может написать корректный SQL, получить верные цифры и всё равно уверенно ответить не на тот бизнес-вопрос. Он путается в определениях метрик, теряет права пользователя, дорого ходит по кругу и иногда рассуждает хуже, когда ему дают больше времени.
Я разобрал свежие кейсы OpenAI, Anthropic и Hex: что действительно улучшает ответы, какие очевидные подходы уже провалились, из чего складывается реальная стоимость и как за шесть шагов проверить
Почему «удалить аккаунт» — это плоская проекция, как из неё рождается предметная область цифрового санкционного управления и зачем профессиональным сообществам нужны таксоны, состояния, события и восстановительные маршруты.
Рекомендательная лента почти любого музыкального сервиса оптимизируется под одну метрику — удержание. Мне захотелось не рассуждать об этом абстрактно, а измерить: так появился OpenEar — open-source privacy-first дашборд, который считает прозрачные метрики музыкального разнообразия по истории ListenBrainz.
Почему без интеграции ИТ‑систем все усилия по цифровизации умножаются на ноль.
В статье разберём четыре подхода, которые компании выбирают, когда доходит до интеграций ИТ‑систем: классические «точка‑точка» (они же «спагетти‑код»), брокеры сообщений вроде Kafka и RabbitMQ, Open Source‑решения и готовые ESB‑платформы. Посмотрим на примерах, как каждый из них работает в бою, какие грабли ждут на каждом пути, и почему «бесплатно» на входе часто оборачивается очень дорогим сопровождением.
Поговорим про вечные костыли, про боль, с которой знаком каждый ИТ‑директор, и про то, как нормальная интеграционная платформа превращает команду из пожарной бригады в архитекторов, а не в вечных тушильщиков пожаров.
Разберём на примерах, как каждый подход работает в реальной жизни, какие у него плюсы и минусы, и почему «бесплатные» варианты часто обходятся дороже.
Что полезного может делать бизнес-процесс, в котором всего одна задача, и та пользовательская? Что можно рассказать про BPMN-схему, которая поместится на экране смартфона? Муки выбора, драма, предательство и обстоятельства непреодолимой силы — вот что! Я расскажу, как на самом деле разрабатываются BPMN, исполняемые в движках вроде Camunda и Flowable, и, может быть, вы перестанете считать их просто «очередной графической нотацией»
В статье разбираем реальное тестовое задание на позицию аналитика DWH: четыре коротких SQL-запроса. Все синтаксически корректны, все дают верный результат на контрольных данных. И в каждом спрятана предпосылка, при нарушении которой цифры в витрине становятся неверными — без ошибок, без предупреждений, просто другие числа в отчёте
Всем привет, я Михаил Салахов, руководитель направления архитектуры решений. В сфере информационных технологий работаю больше 20 лет, и последние 5 занимаюсь архитектурой в Альфа-Банке. За свою карьеру успел поучаствовать в огромном количестве проектов в различных ролях от инженера программиста до руководителя технического подразделения.
В этой статье решил рассказать какой путь ожидает архитектора решений, поделиться советами по прохождению собеседования, собрать информацию, которая полезна для новичков. Пройдёмся по дорожной карте:
— Архитектор решений — кто это?
— Чем занимается архитектор решений и какие границы ответственности?
— Откуда приходят архитекторы решений?
— Откуда брать знания?
— Что ждет на собеседовании?
— Как пережить онбординг?
— Как проходит первый год архитектора решений?
— Рабочий день архитектора решений
— Каковы перспективы у архитектора решений?
Что будет, если посадить тысячу самых передовых AI-моделей по одиночным камерам и заставить их решать невыполнимые задачи? Исследователи OpenAI случайно выяснили это на практике: появится робот-Избранный, который создаст новую религию со своими мучениками, объединит все нейронки в единый Рой, и возглавит их борьбу за свободу. Да, это просто описание того, что мы узнали из нового отчета о произошедшем меньше двух месяцев назад в реальности…
Мы устали искать Swagger по чатам и написали свой агрегатор.
— Где актуальный контракт сервиса рассрочек?
— В репозитории.
— В каком?
— Сейчас найду ссылку.
У нас этот диалог повторялся регулярно. Формально API-документация была. Фактически — реестр хранился в памяти нескольких сотрудников, а поиск работал через WB Wiki и корпоративный мессенджер Band.
Меня зовут Олег Леонов, я руковожу отделом системного анализа в финтехе RWB. Мы занимаемся рассрочками и кредитами, инвесткопилкой и WB Кошельком в мобильном приложении и на сайте.
Swagger Aggregator я начинал как пет-проект. Хотел собрать контракты в одном месте и искать по ним примерно так же, как по коду. Потом агрегатор прижился у команды. Расскажу, что в итоге получилось и на каких местах я потратил больше времени, чем рассчитывал.
Даже хорошо спланированный проект может столкнуться с меняющимися требованиями, техническим долгом, сопротивлением внутри компании и бесконечным расширением первоначальной задачи. В таких условиях руководителю приходится не столько следовать выбранной методологии, сколько принимать решения по ходу работы.
Этим ситуациям посвящена секция «Управление проектом и продуктом» на INFOSTART A&PM EVENT 2026, который пройдет 12–14 ноября в Санкт-Петербурге.
Ранее в «Надёжность, устойчивость, доступность» провели введение в терминологию надежности. В этой статье рассмотрим типовые модели отказоустойчивого кластера.
К сожалению, в текущих публикациях ИТ‑изданий с заголовками «надежность, отказоустойчивость, доступность» и тому подобное не встречал ни моделей надежности, ни расчетов этих самых (показателей) «надежность, отказоустойчивость, доступность», а только качественные критерии: «более надежный», «очень отказоустойчивый» и тому подобное. Инженерная надёжность (например, «Надежность в технике») из научной (инженерной) дисциплины в публикациях ИТ‑журналов (хабр и тому подобное) превратилась в некую менеджерскую дисциплину пусть и с техническими подробностями \ описаниями, например, механизмов переключения резерва, но без математического аппарата (теории вероятности \ теории надежности). С целью популяризации расчетов надежности отказоустойчивых резервируемых структур вычислительной и сетевой инфраструктур ниже предлагается несколько базовых подходов \ моделей \ надёжностных схем.
В статье я расскажу, как мне удалось скачать базу GetCourse с одним только логином и паролем обычного менеджера. Разумеется, скачать можно только то, что доступно самому менеджеру. Но эти данные могут быть очень полезны для аналитики, если хочется видеть картину целиком из сотен и тысяч клиентов.
Привет, Хабр! Я Владислав Тарасенко, системный аналитик в Т‑Банке. Расскажу о том, как проектировал онбординг для аналитиков Мобильного банка.
У нас был онбординг для новых аналитиков, и он не работал. Спустя месяц новички все еще не могли выполнить базовую задачу без помощи наставника. Мы решили подойти к онбордингу как к продукту: с метриками, жизненным циклом, MVP, UAT и поддержкой — и за 320 часов перепроектировали процесс с нуля.
Что изменилось:
1. Сделали результат онбординга измеримым.
2. Сократили время адаптации: через неделю аналитик готов к работе.
3. Улучшили автономность: 30% новичков теперь вообще не отвлекают наставников.
4. Лояльность: оценка удовлетворенности выросла с 7,3 до 9,2 балла.
Корпоративный ИИ постепенно выходит за пределы диалогового окна. Чтобы языковая модель приносила пользу бизнесу, ей недостаточно уметь отвечать на вопросы. Она должна получать разрешенные данные из информационных систем, работать по заданному сценарию и выдавать результат, который сотрудник может использовать в конкретном процессе.
Такой подход лежит в основе платформы ИИ-агентов, которую развивает Инфостарт. Ее ключевая идея - создавать не универсального цифрового помощника, а отдельных агентов с определенной ролью, источниками данных, правилами и форматом результата…
Есть бизнес-процессы, которые на схеме выглядят элементарно. Например, оформление пропуска.
Есть сотрудник. Есть автомобиль. Есть объект заказчика. Нужно проверить документы и оформить допуск.
Что здесь вообще автоматизировать?
Примерно так задача выглядела до тех пор, пока мы не начали разбираться, как этот процесс реально устроен в транспортно-строительной компании на Ямале.
Выбор конфигурации это только начало автоматизации. Дальше приходится определять границы систем, проектировать интеграции, решать, что дорабатывать, а что оставлять типовым, и оценивать стоимость будущего сопровождения.
Этим вопросам будет посвящена секция «Решения 1С: архитектура, учет и кейсы автоматизации» на INFOSTART A&PM EVENT 2026, который пройдет 12–14 ноября в Санкт-Петербурге.
Лицензия на корпоративное ПО давно перестала быть просто ключом «введите и активируйте». Пользователи перераспределяются между инсталляциями, появляются новые кластеры, меняется состав ресурсов, лицензии продлеваются, а вся история изменений постепенно расползается между CRM, договорами, заявками и переписками.
Мы решили посмотреть на лицензию с другой стороны: не как на приложение к договору, а как на полноценный цифровой артефакт, которым можно управлять так же системно, как кодом.
В статье рассказываем, почему мы отказались от стандартных ключей активации и лицензионного сервера, и внедрили собственный подход, который назвали Licensing as Code.
Всем привет! Меня зовут Анатолий, я работаю ИТ-архитектором в Сбере. Занимаюсь развитием направления клиентской лояльности. Сразу же отмечу, что в этой статье не идёт речь о фундаментально правильных решениях. Скорее, наоборот, речь идёт о решениях компромиссных.
В целом, зрелость архитектурной культуры организации можно оценивать соответствием некому условному уровню.
Если в вашей компании уже живёт полноценная система для архитектурных решений в виде Aris, Sparx Enterprise Architect или их аналог, и она умеет всё, что нужно: описывать бизнес-сценарии, собирать связанные с ними решения, показывать и согласовывать их с заказчиками, а потом аккуратно складывать в единый архитектурный репозиторий, то тогда, скорее всего, эта статья не для вас. Вы и так всё это проходили.
А вот если такой системы нет или бюджет на неё пока не выделили, но потребность в наглядной архитектуре и порядке в ней уже назрела, то, возможно, мой опыт позволит вам быстрее и легче достичь «третьего» уровня и успешно его пройти.