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

Аналитик на вебинаре поинтересовался иерархическими индексами для нормативки: дерево «документ → статья → пункт», модель спускается от корня и выбирает ветку, как человек листает оглавление. И сразу про затраты: индексация — это проход по всему корпусу.

Я сравнил такой индекс с B-деревом. Потом сел считать, и сравнение выдержало.

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

Прикинем. Шесть актов на ~200 страниц — глубина 2. 2M токенов — глубина 3. Навигатор читает 8–12 тысяч токенов вместо всего корпуса. А само дерево в законах уже есть: главы, статьи, части, пункты. Строится регекспами по нумерации, без модели. Затраты один раз и только за краткое описание внутренних узлов.

Навигатору остаётся выбрать одну из пятидесяти веток по короткому описанию. Это ближе к классификации, чем к рассуждению. В зале спросили, справится ли с этим модель на 1,5–3 млрд параметров. Интрига.

В статье разберём, какие есть способы получать точные ответы по юридически значимой документации.

От работающей ERP к цифровой реплике и вычислимой модели предприятия

Когда-то, много лет назад, значительная часть моих публикаций на инфоплощадках так или иначе вращалась вокруг довольно простого вопроса: «Купили ERP — что дальше?» Предприятие приобрело большую систему, руководство ждёт от неё результата, проектная команда собрана, консультанты пришли, пользователи продолжают работать — и в этот момент выясняется, что сама покупка программного продукта практически ничего не решает. Нужно понять, что именно внедрять, как организовать проект, как обследовать предприятие, где заканчивается методология и начинается автоматизация, кто принимает решения и каким образом всё это в конечном счёте должно превратиться в работающую систему.

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

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

В одном из проектов мне нужно было развивать управленческую аналитику в крупной образовательной организации. Данные уже были: учебные процессы, финансовые показатели, поступления и другие направления хранились во внутренних системах. Руководству требовались не очередные Excel-файлы, а единый BI-контур с дашбордами, детализацией и регулярным обновлением.

На тот момент я уже работал с Power BI и DataLens, а рабочую версию управленческой аналитики мы развернули на сервере в Visiology. Прототип показали руководству и получили согласование на дальнейшее развитие. То есть на уровне первой демонстрации всё получилось: данные загрузились, дашборды открылись, показатели можно было обсуждать уже не на словах.

Если смотреть только на этот момент, систему можно считать выбранной успешно.

…а не по пинку от внешних расследователей, как это было последние разы (в эпизодах с роем агентов на немецкой вики и со взломом RubyGems). Заодно OpenAI раскрыли шесть новых примеров странного поведения своих моделей, разберем в этом материале кратко самое интересное.

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

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

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

Модульная архитектура ускорила отклик интерфейса и упростила дальнейшее развитие системы.

Ошибки в аналитических витринах часто скрываются за корректным числом строк и успешно выполненным SQL‑запросом. Разберём, как неправильные JOIN и разный уровень детализации данных искажают суммы, почему DISTINCT не всегда помогает и какие проверки позволяют находить такие проблемы.

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

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

Использование криптовалютой обычно считается навыком скорее техническим, хотя основная «техническая» часть там заканчивается на открытии собственного кошелька или заведении аккаунта на криптобирже. Но оживает криптовалюта, из набора цифр превращаясь в цифровые активы, только в транзакциях — то есть, во взаимоотношениях, по обе стороны которых всё так же находятся люди. Особенно когда речь идёт о криптобиржах. Это различие может казаться абстрактным, но становится реальным, как только возникают проблемы, когда понимание характера проблемы необходимо для верного решения: сustodial‑модель означает, что контроль передан бирже в момент, когда средства оказались на её адресе. А, значит, и в решении криптография уже не играет никакой роли — всё решает обычный комплаенс‑процесс, устроенный не сильно иначе, чем в банке. С той лишь разницей, что банк хотя бы обязан по закону объяснить причину отказа в операции, а биржа, зарегистрированная где‑нибудь на Сейшелах, в большинстве случаев — нет.

Я много лет занимаюсь автоматизацией, и как Бизнес-аналитик нередко видел, что по документам 1С процесс может выглядеть законченным: есть заказ клиента, реализация, складские документы и закрывающие документы. Но во время предпроектного обследования выясняются скрытые детали, например: логисты регулярно вызывали курьера, чтобы отвезти бумажные накладные в Россельхознадзор и забрать их обратно! Операция влияла на сроки отгрузки, но существовала за пределами 1С и формального описания процесса.

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

Так возникла задача: хранить в 1С не только BPMN-схемы, но и минимальный реестр описанных процессов.

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

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

Что бы мы ни делали, в результате генерируются данные. А когда ничего не делаем, тоже генерируются – только другие. Все, что сгенерировали, потом анализируют, проверяют, изменяют, продают и используют для генерации новых данных. В 2026 году глобальный объем данных достиг 200 зеттабайт, около половины из них сгенерировал частный сектор.

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

Привет, меня зовут Дмитрий Кузняков, я отвечаю за развитие платформы данных для BI-аналитики в Goodt (ИТ-холдинг LANSOFT), и в этой статье я расскажу, почему мы выбрали подход федерации данных для своего продукта Insight.

Для описания архитектуры важно выбрать подход, который будет понятен всей команде. Одним из них является нотация C4, разработанная Саймоном Брауном.

Данная статья — это продолжение и значительное дополнение моей предыдущей статьи по C4, опубликованной в 2023 году. Здесь я детально разобрала для вас каждый уровень и элемент нотации, распространённые ошибки и спорные вопросы, а также инструменты для создания диаграмм, в частности графический редактор Draw.io и Structurizr для создания C4 через код.

Внутри — много схем, картинок и практических примеров для монолитной и микросервисной архитектуры, готовый код Structurizr и промпт для ИИ. Статья организована таким образом, чтобы вы могли открыть её, последовательно пройти все разделы и самостоятельно разобраться с C4.

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

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

Мало того, что ИИ позволяет обрабатывать и разбирать данные намного быстрее, чем это делалось вручную, так еще и современные BI системы уже позволяют внутри себя задавать вопросы к данным. Это я узнал не так давно, так как сам с этим не сталкивался еще, но это натолкнуло меня на размышления аналитического бытия.

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

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

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

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

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

Ну и поскольку самый наш любимый размер это 256 битовые числа, то попробуем кое-что тут посмотреть интересного.

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

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

Но «похоже на правду» для аналитического отчёта - довольно опасный критерий. Особенно если речь идёт о финансовых показателях.

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

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

В предыдущей статье мы разобрали пятое базовое понятие BABOK — Контекст (Context). Мы выяснили, что контекст — это не фоновое знание, а структурированный анализ среды, который определяет границы возможного решения.

Теперь цепочка почти замкнута: мы нашли нужных людей (Stakeholders), поняли что им нужно (Needs), спроектировали переход (Change), выбрали решение (Solution) и убедились, что оно жизнеспособно в данной среде (Context). Остаётся один — финальный и, пожалуй, самый честный — вопрос:

А зачем всё это было нужно? И как мы поймём, что оно сработало?

Именно на него отвечает шестое и последнее базовое понятие BABOK — Ценность (Value). Оно завершает цепочку. Разберём, что такое ценность в понимании BABOK и почему без её измерения работа аналитика технически никогда не завершена.

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

Ранее в «Базовые модели надежности отказоустойчивого кластера» [2] были показаны теоретические подходы к построению моделей (непрерывная цепь Маркова, CTMC, Continuous‑Time Markov Chain) отказоустойчивого кластера (fault‑tolerant cluster).

Предлагаемый ниже практикум «Промпт‑инжиниринг для моделей надежности отказоустойчивого кластера» имеет цель популяризации практических расчетов надежности «подручными средствами» — через ИИ/AI (искусственный интеллект через AI‑чат, например, ChatGPT). Задача — формализовать промпты для формирования модели надежности и проведения по ней расчета стационарного коэффициента готовности, Кг.

Промпт (prompt) — запрос, текстовая инструкция, которую пользователь даёт нейросети.

Промпт‑инжиниринг — практика проектирования, итерации и верификации текстовых инструкций (промптов) для получения предсказуемых, точных и воспроизводимых результатов от больших языковых моделей (LLM).

Коэффициента готовности, напомним [1], что Кг — численно равен вероятности застать систему (в данном случае кластер) в одном из ее работоспособных состояний (сложение вероятностей каждого такого состояния). Предлагаемые подходы могут быть применены и для других сложных резервируемых структур с учетом ограничений СТМС: случайный процесс «без памяти» с дискретными состояниями и непрерывным временем, а также экспоненциальное распределение времён до отказа/восстановления, независимость отказов компонентов, см. [6], [7].

Специализированные для расчетов надёжности пакеты RAS (Reliability, Availability, and Serviceability) типа SHARPE, MEADEP, RAScad, CARMS, RAPTOR и тому подобное позволяют строить и рассчитывать сложные модели. Есть более простые системы (и бесплатные), которые можно использовать для рассмотренных ранее моделей надежности отказоустойчивого кластера, например, relind.ru. Можно использовать универсальные средства (не специализированные под расчет надёжности), например, для расчета марковских цепей, или расчеты делать непосредственно в Matlab и Mathcad и подобных. Однако все это требует достаточно высокий «порог входа» и имеет встроенные в конкретный soft‑продукт ограничения, как, по существу, так и по визуализации.

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

Ниже я разберу типичные UX‑ошибки на уровне сценария, примеры «как не надо» и «как лучше», а также простые метрики, по которым можно заметить проблему в своём боте.