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

Использование криптовалютой обычно считается навыком скорее техническим, хотя основная «техническая» часть там заканчивается на открытии собственного кошелька или заведении аккаунта на криптобирже. Но оживает криптовалюта, из набора цифр превращаясь в цифровые активы, только в транзакциях — то есть, во взаимоотношениях, по обе стороны которых всё так же находятся люди. Особенно когда речь идёт о криптобиржах. Это различие может казаться абстрактным, но становится реальным, как только возникают проблемы, когда понимание характера проблемы необходимо для верного решения: с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‑ошибки на уровне сценария, примеры «как не надо» и «как лучше», а также простые метрики, по которым можно заметить проблему в своём боте. 

Давным‑давно, аж одиннадцать лет назад, в соответствии с Федеральным законом «О промышленной политике в Российской Федерации» Правительство Российской Федерации выпустило знаменитое Постановление от 17 июля 2015 г. № 719 «О подтверждении производства промышленной продукции на территории Российской Федерации», сокращенно везде именуемое ПП 719. Основной целью данного постановления была стимуляция развития отечественной промышленности. После начала СВО и введения санкций ПП 719 становится ключевым в продвижении любой продукции.

С завидной периодичностью выходят дополнения к данному постановлению, что добавляет азарта в попытках угнаться за фантазиями законотворцев. Меня, как разработчика электроники (на данный момент времени — автоэлектроники) сильно заботят изменения, касающиеся группы II (Продукция автомобилестроения) и группы IX (Продукция радиоэлектроники). Последние редакции ПП 719 в этих группах определены Постановлением Правительства Российской Федерации от 16 марта 2024 г. № 317 «О внесении изменений в Постановление Правительства Российской Федерации от 17 июля 2015 г. № 719».

В одной крупной финансовой компании, где я работал системным аналитиком, технические задания оформляют не в Confluence и не в Word...

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

Продолжение разбора 24 миллионов оценок из Rate Me: как средняя оценка зависит от возраста оцениваемого, почему мужчины и женщины по-разному реагируют на разницу в возрасте, и проверка мифа о взаимности - щедрых оценщиков не оценивают щедрее. Три графика, полный массив, без сэмплирования.

Это уже становится немного смешным (нет), но поток новостей о новых проделках роя нейронок OpenAI в мае‑июле не прекращается — буквально каждую неделю мы узнаем об этом что‑то новое. Причем, сама компания предпочитает эти инциденты замалчивать — но тут уж поможет начавшееся расследование от Сената США.

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

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

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

Стек, чтобы дальше не отвлекаться: .NET 10, C#, WinForms для окна, SQLite (Microsoft.Data.Sqlite) вместо сервера, ScottPlot для графиков, xUnit — 867 тестов на три проекта. Ни одного внешнего сервиса, кроме поставщика котировок, ключ к которому вводит пользователь.