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

Привет Хабр! Мы команда бизнес‑анализа Группы MOEX, и сегодня хотим поделиться своим подходом как мы определяем эффективность нашей работы.

Показателями эффективности являются метрики.

Метрика — это число, которое показывает, как и кто работает. Это не описания, не мнения — только цифры, по которым можно понять: всё хорошо или нужно что‑то менять.

Для нашей команды, мы определили следующие критерии эффективности:

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

Привет, Хабр! Мы — Владимир, Дмитрий и Константин — команда из логистики в торговой сети «Монетка» («Группа Лента»). Мы управляем процессами в одной из крупнейших розничных сетей в России, и у нас — 4+ тысячи магазинов, 40+ тысяч сотрудников и миллионы коробок товара, которые каждый день нужно отгружать со складов 24/7. А выходной – только один день в году, 1 января.

Детская футбольная школа имеет базу данных детей и их родителей, в которой более 7000 уникальных записей. На данный момент посещаемость, продление абонементов и напоминания об оплате происходять в ручном режиме через ERP‑систему.

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

Цель работы: Автоматизировать процесс контроля оплаты и отправки уведомлений, связав интеграцию ERP‑системы с платежным шлюзом и СМС‑провайдером для увеличения выручки школы.

Проектирование процессов и API‑контракта:

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

Схема взаимодействия систем / UML Sequence Diagram

Самые интересные новости финансов и технологий в России и мире за неделю: уголовка косплееру по Warhammer, ограничение сроков льготной ипотеки, Илон Маск запустил летающую тарелку и перестал быть триллионером, падение биткоина, OpenAI выпустили GPT-5.6, а Цукерберг хочет ворваться на рынок предсказаний.

Небольшой обзор идей согласованности в DWH на основе книг Кимбалла.

В статье - краткий разбор некоторых принципов моделирования данных простыми словами.

- Кто такой Кимбалл и каков его подход
- Факты и измерения
- Согласованные факты
- Согласованные измерения
- SVOT, или single version of truth

Привет, Хабр. Меня зовут Владимир Бурмистров, я главный системный аналитик холдинга Т1. В этой статье хочу посмотреть на WebSocket глазами системного аналитика и архитектора: от конкретики протокола HTTP 101 и фреймов до архитектурных решений с API Gateway, sticky‑sessions и формата постановок задач.

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

Это история о том, как идея приходит не тогда, когда ты её ищешь, а когда ты просто идёшь и говоришь с людьми. И о том, как решение делать доклад вдвоём принимается за один вечер.

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

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

В I квартале 2027 г. вендор не будет выпускать обновления 1С:УПП кроме тех, которые потребуются для сдачи отчетности за 2026 г. Законодательные изменения, которые вступят в силу с января 2027 г., поддерживаться в УПП не будут. С 1 апреля вендор приостановит любые консультации по конфигурации (письмо 1С №30064 от 09.12.2022).

В прошлой статье я писал о том, что в концепции 1С:ERP 2026 не хватает предметно-ориентированного слоя. После обсуждения стало понятно, что этот вопрос шире одной ERP-системы: если предприятие уже использует LLM, ему нужен не только набор промптов, а общий семантический контур. В первой статье эта тема была обозначена, но, видимо, недостаточно явно. Исправляю. На мой взгляд, именно этот слой в ближайшее время станет одним из самых практичных и недооценённых артефактов ERP-проектов, СМК-проектов, проектов управленческого учёта и корпоративного внедрения LLM.

Проблема не в том, что предприятиям не хватает ещё одного красивого словаря. Проблема в том, что сотрудники уже используют LLM, и остановить эту реку невозможно. Кто-то работает в ChatGPT, кто-то в DeepSeek, кто-то в Gemini, кто-то в корпоративных чатах, кто-то в локальных моделях. Руководитель просит модель подготовить управленческую справку. Финансист просит объяснить отклонение бюджета. Начальник производства формулирует служебную записку. СМК-специалист готовит проект процедуры. Аналитик описывает бизнес-процесс. Консультант пишет черновик ТЗ. Формально всё выглядит полезно: люди быстрее пишут, быстрее структурируют мысли и быстрее получают черновики документов. Но есть одно слабое место: каждый такой чат начинает строить свою собственную версию смысла предприятия.

В обычной переписке это можно терпеть. В ERP-проекте, в СМК, в управленческом учёте и в производственном контуре это уже опасно. Один сотрудник пишет в модель слово «партия» и имеет в виду партию материалов на складе. Другой под партией понимает производственную партию. Третий — партию для контроля качества. Четвёртый — серию изделия. Пятый — объект прослеживаемости. Шестой — аналитический разрез себестоимости. Модель отвечает уверенно, но отвечает внутри того смысла, который она сама восстановила из контекста. Если этот контекст не зафиксирован предприятием, модель начинает угадывать.

В 2025 году мы работали над концепцией прикладного решения «1С Управление предприятием» для учебного курса УЦ №1 фирмы «1С». В основу легла процессная модель дискретного предприятия, которую мы много лет проверяли на реальных проектах. Видеоматериала получилось около 50 часов, а рабочих наработок — ещё больше.

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

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

Всем привет! Я Светлана Забирова, лид аналитики в Центре разработки и машинного обучения компании «Инфосистемы Джет». В ИТ работаю уже больше десяти лет, из них половину – в заказной разработке.

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

По заданному контексту ИИ хорошо справляются с кодом, миграциями, OpenAPI, сценариями и документацией. Но агентная разработка быстро начинает буксовать, если входной артефакт остается большой постановкой в Confluence, Word или Jira без строгой структуры и трассировки. Модель теряет важные условия, смешивает уровни детализации, дублирует требования или додумывает недостающие связи.

ИИ не будет работать лучше, если аналитики просто «начнут промптить». Задача решается уровнем выше: требования должны стать инженерным артефактом. То есть относиться к требованиям нужно так же, как разработчики относятся к коду.

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

Мы решили проверить подход на одном из пилотных проектов, где было все: аналитика, архитектура, backend/frontend-разработка, тестирование и DevOps.

Как мы перевели аналитику из Confluence/Word в SDD-контур и что из этого получилось, рассказываю под катом.

Кому полезно: бизнес- и системным аналитикам, руководителям команд, архитекторам и разработчикам, которые уже обсуждают SDD, агентную разработку и новые требования к постановкам.

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

Новая Entry/Exit System, или EES, задумывалась как один из ключевых элементов цифровой границы Шенгенской зоны: вместо ручных паспортных штампов система должна автоматически фиксировать въезд, выезд и отказ во въезде для граждан третьих стран, приезжающих на короткий срок. Она собирает данные документа, дату и место пересечения границы, фотографию лица и отпечатки пальцев, а с 10 апреля 2026 года, по заявлению Еврокомиссии, стала полностью операционной во всех странах Шенгена, использующих систему.

Парадокс EES в том, что формально это проект автоматизации, но на практике он временно увеличил ручную нагрузку на аэропорты. Старая процедура — штамп в паспорте — была примитивной, плохо пригодной для аналитики и контроля overstayers, но физически быстрой. Новая процедура создает качественно более богатую цифровую запись, но требует первичной регистрации, биометрии, проверки данных, работы киосков, e-gates, национальных пограничных систем, центральной инфраструктуры eu-LISA, приложений предварительной регистрации и обученного персонала на месте. Иными словами, ЕС цифровизировал не одну операцию, а целую цепочку, где пропускная способность определяется самым слабым звеном.

Давайте разберём кейс подробнее:

Финансовые данные в компании обычно уже есть: в 1С, в хранилище, витринах, аналитических кубах. Но в конце отчётного периода аналитики всё равно часто делают одно и то же: выгружают числа в Excel, собирают сводные таблицы, вручную считают отклонения и готовят презентации для руководства. В этой статье покажем, как перевести такой процесс в промышленный контур: создать OLAP-модель, вынести бизнес-логику в семантический слой и получать живые отчёты в Web, Excel и LibreOffice без ручного копипаста. Выгружать данные будем из 1С, но в виду большого количества способов это сделать мы коснёмся этой темы в следующей статье, а здесь сосредоточимся я на возможностях анализа данных.

Статья будет особенно полезна:

- BI-разработчикам;

- архитекторам данных;

- бизнес-аналитикам;

- финансистам;

- руководителям, которым важно быстро получать корректную управленческую отчётность.

В массовом сознании существует два популярных объяснения очевидной деградации веб-технологий. Конспирологическое — корпорации изначально хотели превратить пользователей в источник прибыли и потому сознательно построили системы манипуляции. Это неинтересно, это мы разбирать не будем. Техноутопическое (самое популярное) — сами технологии нейтральны, а все проблемы вызваны исключительно человеческой жадностью. Это тоже слишком просто — конечно, технологии не нейтральны, и тот же ChatGPT это не «просто инструмент» (так могут думать только технари, не читавшие Маклюэна, Мамфорда и вообще гуманитарную теорию про технологии).

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

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

Рассказываем, с какими темами выступят модераторы и кому будет полезно их послушать...

Сегодня разберемся, что такое кросс-фильтрация в Apache Superset и какую неожиданную опасность она может нести.

В статье описан практический опыт интеграции ERP‑системы с 1С. В материале я рассказываю:
• почему мы выбрали микросервисную архитектуру
• зачем в одной интеграции использовали и GraphQL, и REST API
• как строили маппинг данных для разных конфигураций 1С
• как работает формат EnterpriseData и почему он сложный, но универсальный
• и на какие грабли мы наступали — чтобы вы на них не наступали.

Статья для тех, кто проектирует или сопровождает интеграции с 1С, ищет практические подходы и хочет избежать типичных ошибок.