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

В данной статье-тренажёре мы подготовили 25 заданий на составление BPMN-модели процесса кредитования в ДБО. К каждому заданию мы подготовили рекомендации по его выполнению, а также под спойлерами спрятали наше решение и его объяснение. Возможно, наше понимание и исполнение может отличаться от того, к которому придёте вы — мы будем рады подискутировать в комментариях.

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

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

В статье разберем подход Documentation as Code, почему OpenAPI давно показал его ценность и как развитие ИИ делает структурированную документацию практически обязательной.

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

В дальнейшем к этому добавится проработка связей с внешними и (или) смежными Системами /подсистемами и Компонентами.

Под связями в рамках функциональных требований понимают информационные связи и взаимодействия.

Система управления сервисами — универсальная таблетка для оптимизации сервисных процессов и способ вывести обслуживание бизнеса на новый уровень. Так говорят многочисленные маркетинговые материалы. А как на самом деле? Забегая вперед, скажу: во многих случаях — да, ESM / ITSM действительно полезны. Однако за красивыми цифрами часто скрывается сложный, а порой и болезненный путь. Многие проекты внедрения сталкиваются с неожиданными препятствиями, не достигают заявленных целей или, что еще хуже, создают новые проблемы и заставляют сотрудников искать обходные пути.

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

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

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

В статье расскажу про решение, которое помогло команде платформы аналитики, а затем и целому департаменту аналитики в Туту системно собирать обратную связь и измерять пользовательский опыт. Поделюсь опытом, как нам удалось превратить разрозненные отзывы в систему и как мы заставили метрики «говорить».

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

SQL в 2026: что реально нужно знать аналитику? 🤔
Спойлер: не только JOIN и GROUP BY, а еще и оконные функции, когортный анализ, оптимизация запросов и работа с BigQuery.
Пошаговый план для новичков с бесплатными тренажерами, курсами (да, Карпов там есть) и списком тем, без которых вас не наймут.

Давайте разберем четкий план: что учить, где брать практику и как не потеряться в море информации 👇

JSON:API — это строго типизированная спецификация построения API на языке JSON. Её главная цель — минимизировать количество сетевых запросов и объем передаваемых данных, предоставляя при этом стандартизированный способ взаимодействия.

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

На примере стихотворения "Рассвет на рельсах" можно увидеть эмоции и настроения Марины Цветаевой после отъезда в эмиграцию. В нём преобладают серые унылые тона. Но в то же время есть вера восстановить Россию.

Привет, Хабр! Я Александр, работаю в Центре компетенции аналитики в команде РСХБ.Цифра. Мы отвечаем не только за реализацию конкретных функций, но и за развитие методологий и подходов, которые помогают командам банка работать более эффективно над продуктом «Свои финансы». В этом материале поделюсь мыслями о том, как строить карьеру системного аналитика в банковской сфере, дам практические рекомендации новичкам и тем, кто только задумывается о карьере в этой области.  

Эта статья продолжает цикл BPMN: Beyond the Basics, и сегодня мы поговорим о том, как BPMN управляет временем. Спойлер: весьма посредственно.

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

Привет всем, на связи снова Дарья Борисова, системный аналитик из ПСБ. Продолжаю развеивать мифы о REST API.  В первой статье цикла мы разобрали фундаментальные заблуждения о природе REST. Сегодня переходим к более прикладным, но не менее спорным вопросам — к мифам о реализации. Мы разберем тонкости работы с методами, поговорим о настоящем смысле «stateless» и выясним, правда ли, что новые технологии отправляют REST на покой. Погружаемся глубже.

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

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

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

Вы спокойно работаете, и тут к вам приходит продакт с вопросом по A/B-тесту, который запустили две недели назад. «Ну что, мы уже набрали достаточно трафика? Можно подводить итоги?».

И всё бы ничего, но есть нюанс: на встречу по дизайну этого эксперимента вас позвать забыли. Длительность никто не считал, MDE (Minimum Detectable Effect) не фиксировал.

Чтобы ответить на вопрос продакта, вам нужно посчитать MDE с учетом текущего размера выборки и дисперсии, а затем сравнить его с порогом практической значимости. Выгружать сырые данные только ради того, чтобы посчитать дисперсию в моменте — занятие довольно муторное, особенно если речь идет о неконверсионных (непрерывных) метриках. Даже на highload-проектах, где данных море, тратить время на лишние ETL-операции ради промежуточного чека совсем не хочется.

Но, к счастью, у вас под рукой есть A/B-платформа, которая уже услужливо посчитала доверительный интервал. Например, она показывает вам отложенный эффект: 2% ± 1.5%.

Держите лайфхак: берем половину ширины доверительного интервала (те самые 1.5%), умножаем на 1.43 и получаем наш текущий MDE.

Давайте разберем математику, которая за этим стоит.

Как я заменил Excel-сводные на Telegram-бота и ускорил контроль потерь на складе

Я автоматизировал рутинный процесс, который постоянно отъедал время: сбор выгрузок, построение сводных в Excel, перенос результатов в Google Sheets и ручной контроль повторений. Теперь всё делается одной кнопкой в Telegram: бот берёт последний файл из папки на Яндекс.Диске, обрабатывает данные и выкладывает готовую витрину в Google Sheets. Отдельно он показывает товар, который начнёт списываться в ближайшие 24 часа — это стало не просто ускорением, а новым инструментом управления потерями.

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

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

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

Впервые в истории человечество может генерировать программное обеспечение быстрее, чем способно понимать создаваемые системы.

На протяжении многих лет индустрию программного обеспечения волновал один вопрос:

Кто будет писать код?

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

Но это порождает гораздо более важный вопрос — тот, который почти никто в технологическом мире не задаёт:

Кто будет нести ответственность за жизнь программных систем, которые ИИ собирается создавать?

Потому что написать код легко.
Жить с последствиями этого кода следующие двадцать лет — значительно сложнее.

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

1️⃣ Написание кода
2️⃣ Проектирование алгоритмов и систем
3️⃣ Ответственность за жизненный цикл программного обеспечения

Эти роли часто воспринимаются так, будто это одно и то же.

Но это не так.

И появление ИИ заставляет нас наконец увидеть эту разницу.