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

Одна из особенностей, выделяющих роль системного аналитика среди всего многообразия позиций в ИТ, —  его зона ответственности, а точнее — границы этой зоны. Поскольку он находится на стыке разработки и бизнеса (не говоря о том, что часто выступает в роли интегратора, Delivery manager, Product manager, Scrum master, архитектора и так далее), лучше всего эту работу можно описать картинкой ниже.

Время от времени в руки SA попадают «непрофильные» задачи, которые могут стать настоящим вызовом, выковать характер или причинить ментальные муки. Но чаще все вместе.

И снова привет, Хабр! На связи Александр Малышев, лид SA в МТС Cashback. Это продолжение истории про «рыцаря системной аналитики без страха и упрека» в которой я рассмотрел дилемму изменчивости требований. Вторая часть посвящена зоне ответственности SА. Так как вопрос довольно непростой, то я решил подать его в нетипичной для Хабра и юмористической форме — стихотворной истории в духе народных сказок.Тем, кто хочет немного отвлечься от рутины — желаю приятного чтения!

Шестьдесят дней назад я держал всю координацию своего SaaS в голове. Двенадцать вкладок Claude Code, в каждой своя роль: тимлид, аналитик, тестировщик, медиабайер. Я переключался между ними и был единственным местом, где эти вкладки узнавали друг о друге.

Сейчас в очереди 1002 задачи, из них 954 закрыты. Медиана от постановки до закрытия составляет 47 минут. Вся координация умещается в 600 строк Python на стандартной библиотеке и один markdown-файл.

Статья про то, как устроена координация. Не про то, что я попробовал модный инструмент, и без советов «промптите лучше».Три подхода, которые не сработали. Один, который сработал. Отказ, стоивший мне двух рабочих окон. И метрики, которые я не приукрашивал.

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

Недавно мы выкатили новость (кейс) о совместном проекте с компаниями «Полиэкс» и PIX BI о построении аналитической платформы (почитать можно тут). Все чинно-благородно (новостной язык суров): сроки, интеграции, архитектура. Но у нас с коллегами родилась идея – сделать перевод с делового языка на человеческий. И мы записали интервью с участниками проекта. Команда PIX BI задавала вопросы, а GlowByte и «Полиэкс» говорили как есть: от GlowByte – руководитель проектов Роман Прохоров, со стороны АО «Полиэкс» – ведущий аналитик службы стратегического развития Арина Бортникова.

В предыдущей статье мы рассмотрели общий процесс работы аналитиков. 

Здесь подробнее остановимся на ключевых этапах подготовки постановки.

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

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

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

Всем привет!
Меня зовут Дмитрий Яшаяев, я работаю системным аналитиком, а ещё путешествую по миру на мотоцикле.

Многие писали и интересовались, куда я пропал и почему не пишу. Вы, возможно, ждёте продолжения рассказа о первом этапе моей «кругосветки», о пути из Москвы к Персидскому заливу в Иране. Я обязательно к нему вернусь. Но сегодня хочу отойти от хронологии и поделиться историей, которая произошла со мной в прошлом 2025 году во время пятого этапа путешествия, история, которая стала серьёзным испытанием и во многом изменила мои планы.

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

Привет! Я Ольга Матушевич, преподаватель курса «Нейросети для бизнеса», а в прошлом ментор Мастерской Яндекс Практикума. В e-commerce и маркетинге есть множество наработанных методик. Но как применить их там, где цель — не прибыль, а спасение жизней? 

Хочу поделиться кейсом Мастерской: мы работали с DonorSearch — крупнейшим сообществом доноров крови в Рунете. Заказчик поставил задачу: сегментировать донорскую базу так, чтобы можно было вести адресную коммуникацию с разными группами доноров. Понять, кого считать активным донором, кто выпал из донорства, а кто только начинает свой путь — и что делать с каждой из этих групп. 

Мы выбрали необычное решение — применить RFM-анализ, классический инструмент из маркетинга. В статье я расскажу:

— почему мы отказались от машинного обучения в пользу с-анализа,
— как переосмыслили классическое определение метода под некоммерческую задачу,
— чем заменили «деньги», «покупки» и «покупателей» в RFM-анализе,
— и к каким семи классам доноров в итоге пришли.

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

Чек-лист для тестирования поисковых и RAG-систем — от базовой работоспособности поискового движка до качества генерации, агентных сценариев и поведения на неполных данных. Шесть уровней проверок, сводная таблица с инструментами для каждого уровня и глоссарий из 50+ терминов. Проверку стоит организовывать по порядку, нет смысла гонять RAG-метрики, если система не проходит Уровень 0, то проблема может быть в том, что поиск не находит документ из-за опечатки в запросе, а не в качестве генерации.

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

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

«Освоить профессию с нуля» — популярный запрос, но не всегда корректный. А что, если абсолютного нуля не бывает? Ведь у каждого из нас есть свой опыт, знания и преимущества в чём-то своём.

Хабр, привет! Меня зовут Альберт Болотнов, я главный системный аналитик продукта в бигтех-компании. Я отучился на инженера в МГТУ им. Баумана, но через два года работы сменил сферу на IT, а ещё спустя год — добрал необходимые знания в курсе «Системный аналитик» в Яндекс Практикуме. В этом тексте расскажу про свой путь и дам несколько советов тем, кто ищет себя или делает первые шаги в профессии.

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

В этой статье разберём, как на ArchiMate 4.0 собрать первую рабочую модель предприятия с нуля — на примере интернет‑магазина, с понятной логикой доменов, связей и проверок, которые помогают не превратить диаграмму в клубок стрелок.

Я работаю более 6 лет системным аналитиком и порядка трёх лет на продуктах по внедрению LLM в бизнес. И меня категорически не устраивает AI-зрелость большинства моих коллег в этих ИИ-проектах!

Есть мысль, что часть проблемы в отсутствии у системных аналитиков общепризнанного подхода к AI‑усилению, подобного тому, что уже сформировался у разработчиков. Но при этом я часто встречаю в вакансиях требования «опыт написания документации AI‑native», «AI‑центричная аналитика». И я согласен с таким запросом рынка — давайте уже подстраивать пайплайн под эксперта! А эксперты в процессе написания кода — это наш разработчик + AI. Очевидным и логичным решением будет писать аналитику сразу в текстовом формате, постепенно уходя от Miro и Draw.io.

Первое время я даже считал, что придумал новый фреймворк, и даже придумал ему красивое название — Analysis‑as‑Code, но оказалось, что существует Spec‑Driven Development — подход, в котором «спецификация» становится центральным документом, а ИИ использует её в реализации задачи.

В этой статье я хочу разобрать Spec‑Driven Development (SDD) с оглядкой на роль системных аналитиков в России и СНГ и понять, как их меняется их роль при таком подходе.

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

Если вы думаете, что главная сложность совместного выступления — это разница во времени или плохой интернет, вы ошибаетесь. Главная сложность — это быть двумя разными экспертами с двумя разными «я», которые пытаются зазвучать в унисон, находясь за 1500 километров друг от друга. Мы прошли через это. И теперь, оглядываясь назад, я понимаю: онлайн-подготовка и очные репетиции — это два разных мира. И нам повезло, что мы успели побывать в обоих.

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

Внедрение ERP? Интеграцию ERP с MES? Замену импортной PLM? Подготовку регламентов? BI-панель? Электронный документооборот? Производственную аналитику? Новые рабочие места в системе? Всё это может быть полезно, а иногда и совершенно необходимо. Проблема начинается в тот момент, когда обычная автоматизация, внедрение или интеграция начинают называться цифровой трансформацией предприятия.

Эта статья не про конкретную компанию и не про конкретную конференцию. И тем более не про персональные оценки людей, которые занимаются внедрениями. Речь о другом: на рынке сложился язык, в котором слово «цифровизация» часто используется слишком свободно. Иногда под ним понимается реальное изменение способности предприятия управлять собственной деятельностью, но часто — просто поставка цифрового инвентаря: систем, документов, интерфейсов, интеграций и отчётов.

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

В B2B‑маркетинге чаще всего платят не за трафик, а за неоптимизированный процесс. В одной из компаний мы получили классический сигнал: в отчёте — много заявок, а в бизнесе — ощущается пробел. Это было не «плохой канал», это было «мы теряем деньги между лидом и сделкой».

В проекте с IT‑B2B, продажи от 1,2 млн, цикл 3–4 месяца, диагноз выглядел так:

42% заявок не доходили до клиента; 33% коммерческих предложений терялись на этапе подготовки; основной источник закрытых сделок получал только 18% бюджета. Я не прикрываю это «кейсом», я говорю о простой вещи: деньги утекают ещё до того, как начинаются кампании.

«Мне повезло» — так я начал свой отзыв на «Авито», ещё не подозревая, насколько мне повезло на самом деле.

Мне нужно было найти исполнителя в незнакомой сфере. Я, как обычно, зашёл на «Авито», промотал первые результаты (не хочу оплачивать маркетинговые бюджеты тех, кто пробился в топ) и нашёл Сергея. Высокий рейтинг, хотя отзывов немного. Услуга — междугородний трансфер. В поездке я убедился: повезло. Сергей — настоящий профи, автомобиль в идеальном порядке.

Уже в дороге Сергей пожаловался: «Авито» отклоняет отзывы его клиентов. Алгоритм считает их накрученными. «Без проблем, — подумал я, — оставлю отзыв. У меня старый аккаунт, куча заказов, система меня точно не посчитает меня ботом». Как же я ошибался.

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

Если коротко, то произошло следующее.

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

Подробности под катом.

Привет, Хабр! Меня зовут Александр, я работаю в IT с 2006 года, последние годы занимаюсь системным анализом и управлением командами аналитики.

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

Для кого-то T-Shaped — это специалист, который понимает систему шире своей основной области и умеет эффективно взаимодействовать со смежными ролями. Для кого-то — тот, кто должен «уметь всё понемногу». А иногда под этим термином вообще начинают подразумевать сотрудника, который фактически совмещает несколько ролей одновременно. Короче говоря, с T-Shaped все далеко не так однозначно.

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

Привет, Хабр! Мы — Анастасия Назарец, Артем Вожаков и Антон Филин из отраслевого центра компетенций IBS в машиностроении. В этой статье расскажем, почему решили сделать собственную систему проектирования прикладных решений при живой «1С:СППР» и как новая комплексная система реализации проектов улучшила не только нашу жизнь, но и жизнь заказчиков.

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

Статья будет полезна системным аналитикам и backend-разработчикам, которые проектируют интеграции с внешними API, используют OAuth 2.0 и хотят разобраться в практических сценариях — включая фоновые операции.