Профессия: Бизнес-аналитик

От запроса к решению

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

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

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

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

Границы соседних профессий

Системный аналитик обычно подробнее описывает поведение информационной системы, структуры данных и взаимодействие компонентов. Бизнес-аналитик чаще начинает с целей и работы организации. Граница подвижна: одному человеку могут поручить обе части. Если вакансия требует API, SQL и интеграционные схемы, это означает, что придётся обсуждать технические детали, даже если должность называется бизнес-аналитиком.

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

В Scrum, одном из подходов к организации продуктовой работы, руководство определяет ответственности Product Owner, Developers и Scrum Master. Отдельная ответственность бизнес-аналитика там не выделена. Это не мешает аналитику работать в такой команде: его задачи распределяются внутри принятой организации работы. Нельзя считать, что наличие должности автоматически даёт ему право менять порядок продуктового бэклога [4].

Практическое следствие простое. На старте спросите: кто принимает решение о составе решения, кто подтверждает бизнес-правила, кто отвечает за техническую архитектуру и кто принимает результат. Ответы должны содержать имена или конкретные роли. Фраза «согласуем с бизнесом» оставляет слишком много неопределённости.

Что считать хорошим результатом

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

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

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

Форматы работы и доход

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

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

На сайте hh Карьера в материале о профессии приведён ориентир за 2025 год: средняя зарплата бизнес-аналитика 120 тысяч рублей, для Москвы 144 тысячи, для Санкт-Петербурга 122 тысячи. Эти числа нельзя считать актуальной гарантией дохода или вилкой для новичка. В опубликованном фрагменте не раскрыта вся методика расчёта; показатели относятся к разным специалистам и конкретному периоду [5].

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

Практикум о выборе роли

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

Предположим, первая вакансия требует описывать процессы обслуживания, вторая — разрабатывать API-контракты, третья — строить отчёты в BI-системе. Все три могут содержать слово «аналитик». Но подготовка к ним различается. Для первой убедителен кейс с BPMN и изменениями процесса, для второй нужны сценарии обмена и структуры сообщений, для третьей — корректные расчёты и работа с данными.

Составьте краткую формулировку своего направления: «Хочу заниматься исследованием процессов и требованиями к внутренним системам». Она поможет выбирать задания и вакансии. Это рабочий ориентир, который можно уточнять. Не нужно обещать себе освоить все аналитические специальности одновременно.

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

Исходная ситуация

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

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

Руководитель формулирует запрос: «Хочу видеть, что происходит с каждой заявкой, и сократить задержки первого контакта». Здесь уже есть два возможных направления: прозрачность работы и скорость общения. Они связаны, но не тождественны. Новый экран статусов может улучшить первое и почти не повлиять на второе, если администратор не успевает звонить.

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

Перед выбором решения нужно проверить именно эти вопросы. Предварительный показатель задержек равен 72 / 240 = 30%. Он описывает учебную выборку и ещё не доказывает причину проблемы. Сотрудники могли не записывать своевременный звонок; в таком случае часть «задержек» окажется дефектом данных.

Паспорт проекта

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

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

Цель первой версии — обеспечить единый учёт принятых заявок и контроль первого контакта после диагностики. Учебный целевой показатель: доля заявок с просроченным первым контактом не выше 10% в согласованном периоде пилота. Значение выбрано для упражнения и должно быть подтверждено заказчиком после проверки исходных данных и возможностей процесса.

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

Ограничения учебного проекта: сотрудники пользуются браузером на рабочих компьютерах; связь иногда пропадает; у мастеров нет времени заполнять длинные формы; руководитель хочет начать с небольшого пилота. Эти условия повлияют на интерфейс, правила ошибок и объём первой версии.

Документы и версии

Создайте папки «Исследование», «Процессы», «Требования», «Проверки» и «Портфолио». Имена файлов должны объяснять содержимое. Например, «Процесс приёма v0.2» полезнее, чем «Новая схема окончательная 3». Внутри документа отмечайте дату, автора изменения и его смысл.

Статус документа и его версия решают разные задачи. Версия показывает конкретное состояние текста. Статус показывает положение в работе: черновик, на проверке, согласовано или заменено. Документ версии 1.0 может оставаться на проверке. Не выводите согласование только из номера.

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

Пример записи: «Первую версию запускаем без автоматических сообщений. Причина: сначала нужно наладить фиксацию контакта и проверить канал связи. Решение влияет на требование FR-06 и на сценарии приёмки». Это позволяет позднее объяснить, почему ожидаемая функция не вошла в релиз.

Инструменты

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

Для схем полезны редакторы с проверкой связей и экспортом в изображение или BPMN XML. Однако встроенная проверка не обнаружит неверное бизнес-правило. Схема может быть технически корректной и описывать процесс, которого в компании нет. Согласование с участниками остаётся отдельной работой.

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

Использование ИИ

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

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

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

Задание на начало проекта

Подготовьте паспорт на одну-две страницы. Затем выпишите десять вопросов, ответы на которые могут изменить решение. Обязательно включите вопросы о начале отсчёта задержки, определении контакта, распределении заявок и работе при отсутствии связи. Для каждого вопроса укажите, у кого или в каком материале искать ответ.

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

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

Как уточнять проблему

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

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

Разделите наблюдение, объяснение и предложение. Наблюдение: дата контакта записана позже диагностики. Объяснение: уведомление могло затеряться. Предложение: показывать список заявок, ожидающих контакта. Если записать всё одним пунктом, гипотеза превратится в кажущийся факт.

Техника последовательных вопросов «почему» помогает двигаться от симптома к возможной причине, но не выдаёт объективную истину сама по себе. После каждого ответа спрашивайте, чем он подтверждён. Если сотрудник говорит «мастера забывают», проверьте, где они должны отмечать готовность и знают ли они это правило.

Цель и показатель

Цель описывает нужное изменение. Показатель делает его наблюдаемым. Для проекта выберем долю заявок с просроченной первой попыткой после диагностики, включая отсутствие попытки после истечения срока. Нужно определить знаменатель: все пригодные заявки с завершённой диагностикой, срок контакта которых наступил в выбранном периоде. Заявки с ещё не наступившим сроком нельзя автоматически записывать в успех.

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

Если диагностика завершена в пятницу в 16:00, два рабочих часа проходят до закрытия, ещё два — в понедельник с 09:00 до 11:00. Контакт в понедельник в 10:30 укладывается в срок. Простое прибавление четырёх календарных часов дало бы пятницу 20:00 и исказило показатель.

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

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

Карта участников

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

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

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

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

Контекст и границы

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

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

Составьте перечень внешних зависимостей: доступ к сотрудникам, действующие правила приёма, рабочий календарь, согласованный состав данных, оборудование и сеть. Для каждой зависимости назначьте способ проверки. Если правило отсутствует, это не повод молча придумать его в ТЗ. Это отдельное решение заказчика.

Практикум по границам

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

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

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

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