Системный и бизнес-анализ

Есть множество инструментов для создания AI-агентов, и в основе им нужно три вещи. Во-первых, им нужно понимать свою основную цель и правила, в рамках которых они должны работать. Например, вы можете создать агента и сказать ему: «Ты здесь, чтобы помогать клиентам с общими запросами о существующих услугах банка». Во-вторых, нам нужен промпт — это запрос к агенту, который агент может попытаться выполнить. И наконец, нужен набор инструментов — это действия и системы, к которым агент имеет доступ, чтобы исполнить запрос.

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

Хабр, привет! Меня зовут Вячеслав Демин, я больше четырёх лет работаю в сфере Data Science. Сейчас руковожу направлением аналитики данных в Сбере и преподаю на курсе «Специалист по Data Science» в Яндекс Практикуме. Начинал с этого же курса в 2020 году, после чего работал в сфере страхования и нефтехимии.

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

После моей первой статьи про пирамиду ICN Holding поступил аргументированный (ну как…) ответ на подсвеченные мной красные флаги. В этом материале мы их подробно разберем – и еще раз убедимся, что, как ни крути, в красивую и легальную картинку этот пазл никак не складывается.

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

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

Эта статья — о том, как методы анализа контекста и внимания к «неважным» и неозвученным деталям позволили мне разглядеть в пунктах тестового задания очертания будущего рабочего места. О том, почему я принял решение не отправлять выполненную работу (после шести дней разбора заданий).

Привет, Хабр!

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

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

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

Поехали!

Представьте переводчика. Один специализируется на технических мануалах, другой — на юридических контрактах, третий — на медицинских исследованиях. Знание языка — база, но уникальными экспертами их делает знание и понимание особенностей языка в определенной сфере. Системные аналитики — такие же «переводчики» между бизнесом и ИТ, и их «специализация» (предметная область) критически важна.

Меня зовут Любовь Вайгель. Я системный аналитик MedTech-компании №1 в России — СберЗдоровье. Чтобы разобраться, как работа системного аналитика отличается в разных предметных областях, и как специалистам мягче пройти смену профиля компании, я провела собственный анализ. Подробно о полученных результатах — в статье.

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

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

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

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

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

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

Это история о попытке создать новую логику.

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

Я построил концепцию, где смысл — не точка, а процесс, бесконечный и самоподобный. Но концепция осталась без семантики.

И тогда я решил устроить суд Божий: я дал свою книгу двум арбитрам — искусственным интеллектам. Я ожидал диалога, но получил войну.

Qwen, стремясь к формализации, строил сложные системы. DeepSeek, как строгий судья, разрушал их одну за другой, обвиняя в "иллюзии формальности" и "магии".

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

Это — отчет с поля боя за семантику.

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

Сегодня рассмотрим вариант, когда события произошедшие уже офлайн, отправляются обратно в онлайн статистику Яндекс Метрики и обогащают ее. Это позволит делать рекламу и собирать аудитории в Яндекс Директе точнее еще на 30-35%

В статье рассматриваются проблемы, возникающие при оценке эффектов A/B-тестов и Causal Inference в ритейле, когда необходимо анализировать изменения выручки по различным категориям товаров и общей (тотал-) категории. Мы подробно рассмотрим, почему простое суммирование оценок эффектов по категориям не всегда дает корректную оценку для тотал-категории, и предложим эффективный способ решения этой проблемы.

 Привет!

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

Курс «Специалист по Data Science» — один из первых в Яндекс Практикуме. Он запустился в 2019 году — за это время рынок и требования работодателей поменялись, а значит, должны меняться и учебные программы.

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

Самые интересные новости финансов и технологий в России и мире за неделю: Google Meet начал сбоить в РФ, в ЕС планируют сканировать все переписки в мессенджерах, в секс-ботов Grok добавили новые наряды, переписки c Гроком оказались в публичном доступе, а еще GPT-5 научился говорить «я не знаю».

Продолжение цикла статей о проектировании информационных систем.

Все статьи:

Введение

Видение системы

В этой части рассмотрим сущности Use Case и User Story

Одно недопонимание на встрече может стоить вам недель переделок. В этой статье рассказываем, какие визуальные нотации помогут бизнес-аналитикам и командам понимать друг друга без лишних ошибок. Простые схемы и диаграммы, которые ускорят работу и сделают процессы понятнее для всех: от заказчика до разработчика. Узнайте, как выбирать и применять BPMN, ERD, Sequence Diagram и User Story Mapping в реальных проектах.

Попытка по-иному ответить на вопрос «какую BI‑систему выбрать»? Вместо сравнения систем сделаем проще — оценим рынок и расскажем о возможностях той системы, которую предпочли топы.

Всем привет. На связи Даша Леонова, product owner и ранее product analyst в международной IT-компании Garage Eight. Недавно я открыла конференцию AHA!25 с докладом об A/B-тестах для опытных аналитиков и продуктовых менеджеров. Делюсь: вышло круто. В статье расскажу о том, как вырастить компетенции аналитика за три этапа, начать проводить эффективные A/B-тесты, и стать партнером для компании, а не рядовым сотрудником.

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

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

Исходные условия: у нас было мобильное приложение, написанное на Objective-C (iOS) и Java (Android). Цель — переписать его на современный стек: Swift и Kotlin. Дополнительно нужно было сделать редизайн приложения и обновить бэкенд: поднять Java с 6 до 21. Приложение общалось с бэкендом по HTTP и использовало Protobuf для сериализации данных.

Что важно — никакой документации на существующее приложение не было. У нас была лишь тестовая сборка и сервер с логикой. Поэтому перед стартом разработки нужно было:

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

 Пару слов о нашей команде и о том, чем мы занимаемся. У нас 6 инженеров данных и 5 аналитиков — вместе мы помогаем продуктовым командам (тем, кто развивает сайты и приложения) создавать дашборды и отчёты. Они нужны для того, чтобы коллеги видели, как их изменения влияют на бизнес-метрики и поведение пользователей.

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

Как появилась задача

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

Однако наш продукт выдавал отчёты только к 16:00. Кому-то хватает часа на подготовку, кому-то трёх, но пользователи жаловались: они просто не успевают осмыслить данные и сформулировать выводы.

Коллеги обратились к нам с запросом: перенести формирование отчетов на 12:00, чтобы оставалось больше времени на анализ. И мы стали думать, как это сделать своими силами без увеличения команды.