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

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

Привет, меня зовут Янина. Днем я управляю продуктами и проектами. Вечером — сижу в Jitsi с ребятами из IT и обсуждаю, почему у кого-то не полетел A/B-тест, как считать retention и что вообще считать ценностью в продукте. Мой разговорный клуб давно перестал быть просто поболтать на английском.

Раньше основой домашек были подкасты про какую-то боль в аналитике. Но в какой-то момент я поймала себя на мысли, что про аналитику очень сложно слушать. Ее лучше видеть (дашборд, cjm и тд). Поэтому в клуб пришли воркшопы и лекции из YouTube. И сегодня делюсь каналами, которые у нас в итоге прижились.

Если хотите, чтобы просмотр видео был максимально полезным для вашего английского, то:

Представьте: вы заходите в репозиторий, открываете папку schemas и через пять минут понимаете, как устроена база во всём проекте, со всеми связями. Никаких устаревших диаграмм в Confluence, никаких гаданий по коду миграций. Схема базы данных становится частью кодовой базы — её можно версионировать, ревьюить, тестировать. Модель в формате ArchDB становится единым источником истины, из которого автоматически генерируются документация, DDL-скрипты и даже ORM-сущности. Звучит как мечта? Для нас с командой это стало реальностью, когда мы перешли на ArchDB.

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

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

Excel довольно универсальный инструмент. Хочешь — отчет собери, хочешь — модель посчитай, хочешь — гипотезу проверь. Но постепенно его начинает не хватать.

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

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

Тогда многие компании начинают задумываться об усовершенствовании аналитики и внедрении BI.

Данный материал подходит для тех сотрудников, которые не имеют опыта работы или недавно пришли на проект, связанный с хранилищами данных.

Сегодня хотим рассказать вам о рабочих буднях аналитика DWH, точнее об одной из частей этих будней. Надеемся, данное знание пригодится вам для того, чтобы быстро и без нервов освоиться на том проекте, на котором вы будете работать.

Информацию описываем вам из нашей практики работы нашего аналитика хранилищ данных.

Работу аналитика хранилищ данных можно разделить на две части:

1. Организация интеграции данных от какого‑либо источника к какому‑либо приемнику;

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

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

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

В статье речь пойдет об ETL-процессе, когда с источника данных «протянут» информационный поток со своей логикой преобразований, который «кладет» некорректные данные в приемник.

Когда-то я был молодым и активным. И под воздействием средств массовой информации, окружения и прочитанных довольно глупых книг я искренне считал, что человек с активной жизненной позицией, прилагающий значительные усилия, может в жизни добиться всего. В целом, я и сейчас наблюдаю такую же позицию у активной части молодёжи. Более того — в технологической среде эта вера ещё сильнее. Hustle culture, гаражные мифы Кремниевой долины, «если ты не добился — значит, мало хотел».

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

Знакомо?

Главной темой форума 3 апреля 2026 года станет путь к инновационному и высокотехнологичному государству.

Не прячась за красивыми словами перейдём к делу: ниже вкратце описаны основные шаги и проекты стратегии по развитию и процветанию России до 2100 года.

Всем привет! Меня зовут Александр. Я работаю в компании которая ведет управление личными кабинетами на маркетплейсах. И вопрос аналитики стал для нас проблемным. Испробовав много сервисов аналитики мы так и не смогли найти подходящий. Тут одно хорошо, там другое. А в кучу все собрать сложно. Мы начали тратить на это слишком много времени.

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

В этой статье я хочу рассказать как мы от потребности в нормальной аналитике WB и OZON прошли путь до создания своего SaaS - продукта на Datalens + PostgreSQL с оптимизацией JOIN’ов, историей себестоимости, автоматизацией процессов и классными решениями.

✨ Самоадаптирующаяся ИИ-система, актуализирующая критерии каскада ликвидаций

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

Всем привет! На связи Анастасия, руководитель отдела сопровождения финансового учета в компании ecom.tech/1C. В этой статье я хочу на примерах показать, как AI начинает вписываться в систему 1С.

Привет, Хабр! Я Наталья Самсонова, фулстек-аналитик в ГК «Юзтех». Последнее время работаю пресейл-аналитиком в продуктовой команде. Несколько десятков встреч с клиентами в этом качестве позволили мне заметить значительную разницу в целеполагании заказчиков в проектах заказной и продуктовой разработки. О чем конкретно речь и почему это важно при выборе интеграционной платформы — рассказываю в статье.

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

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

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

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

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

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

Обратная ситуация - если бы в компании была единая, поддерживаемая и согласованная модель деятельности, которую можно «взять» как основу для любой задачи на автоматизацию. Такая модель и есть процессная архитектура организации.

Постмодерн - это современный способ мыслить. Я его определяю, как "продуктивная борьба со смыслом". Пусть грубо, но более лаконичной формы я не нашел.

Каждый год Ларри Финк, глава крупнейшей в мире инвестиционной компании BlackRock (активы которой только за 2025 год выросли на $698 млрд), публикует открытое письмо инвесторам. Обычно такие письма воспринимаются как скучная корпоративная отчетность, но не в этот раз.

Добрый день, дорогие читатели!

Поделюсь с вами опытом составления артефакта, который объединяет уровни абстракции проектируемого решения в одном месте: развертка вариантов использования по статусной модели с маппингом на API.

Практический разбор на примерах: сбор требований, диаграммы, Use Cases и ТЗ. Плюсы, минусы,подводные камни и промт-чеклист для системного аналитика.

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

Когда компания решает автоматизировать учёт на 1С, подрядчики предлагают обследование. Многие заказчики считают это лишней бюрократией. Но именно на этом этапе закладываются сроки, бюджет и будущее системы. Рассказываю, какие 11 ошибок совершают заказчики по собственной инициативе и к чему они приводят.

Всем привет! Меня зовут Наталья, я ведущий системный аналитик в MWS. В ИТ полно примеров того, как попытки решить задачу приводят к появлению совершенно непригодных инструментов. Формально они работают, но пользоваться ими либо крайне неудобно, либо невозможно. Кнопку вроде сделали, но кривую и не там. Сайт работает, но падает под нагрузкой. Парковку предусмотрели, но только для 10% клиентов.

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

Самые интересные новости финансов и технологий в России и мире за неделю: в столице опять дали интернет, новый биржевой фонд Лежебоки, уголовка за незаконный майнинг в РФ, штраф Метогуглу за подсаживание на соцсети, Илон Маск строит крупнейший в мире чиповый завод, долгожданный аудит Tether, а также первый тизер нового ГП-сериала.