Системная и бизнес аналитика
Статью подготовили Антон Тризна
, руководитель центра компетенции по бизнес-анализу a1qa, и Елена Горопека, старший бизнес-аналитик компании.
В профессиональной среде постоянно ведутся дискуссии о том, в чем разница между бизнес-аналитиком и системным аналитиком в IT.
Разбираться в этом вопросе мы будем с опорой на существующие определения.
Согласно настольной книге бизнес-аналитиков, BABOK (Business Analysis Body of Knowledge), бизнес-аналитик может «скрываться» под множеством должностей и ролей в организации: бизнес-архитектор, аналитик данных, аналитик на предприятии, бизнес-консультант, аналитик процессов, инженер по требованиям, системный аналитик.
Также BABOK подчеркивает, что результатом работы бизнес-аналитика является разработка «решения, позволяющего организации достичь своих целей», т.е. решением не обязательно должна быть IT-система.
Исходя из этого, можно говорить о том, что бизнес-аналитик — это общее название для группы профессий, работающих с требованиями бизнеса для достижения некоторой цели. В сфере IT зачастую аналитики подразделяются в зависимости от того, в какой области сконцентрированы основные знания специалиста: в области информационных технологий или в доменной области заказчика.
Какие бывают аналитики?
Зарубежная практика бизнес-анализа, более развитая в теоретической части, чем отечественная, также рассуждает о различиях между бизнес-аналитиком и системным аналитиком и приходит к выводу, что все зависит от политики, принятой в компании, от компетенции каждого конкретного человека и того, с кем в рамках проекта больше взаимодействует аналитик.
В компании a1qa мы используем следующие определения:
- Бизнес-аналитик — специалист, использующий методы бизнес-анализа для проверки потребностей заказчика с целью определения возможных проблем и последующей выработки путей их решения.
- Бизнес-аналитик в IT-сфере — бизнес-аналитик, который обеспечивает решение проблем заказчика с помощью разработки и внедрения IT-систем.
- Системный аналитик в IT-сфере — специалист, ответственный за определение технических аспектов разрабатываемой IT-системы, а именно, за выработку подхода к разработке IT-системы, определение платформы реализации, способов интеграции, места системы в линейке продуктов компании.
Бизнес-аналитик выясняет потребности клиента и обосновывает необходимости реализации проекта. После этого на основании выявленных бизнес-требований и пользовательских требований клиента аналитик определяет границы проекта.
Следующей стадией является сбор функциональных и нефункциональных требований. На этом этапе к работе бизнес-аналитика может подключиться системный аналитик. Разница в том, что бизнес-аналитик не учитывает платформы реализации и технологии, а стремится максимально учесть все пожелания и цели заказчика, обеспечить полноту, корректность и непротиворечивость требований. Задача же системного аналитика — принять во внимание все особенности работы с определенной технологией и платформой и выбрать оптимальный способ реализации всех заявленных функционально-технических требований.
Бывает так, что платформа и технологии были выбраны заранее. Тогда необходимо грамотно распределить функциональные требования на выбранной платформе, адаптировать их описания под термины выбранной платформы и интерфейсов взаимодействия для команды разработчиков.
Проработав все требования, аналитики начинают консультировать команды разработки и тестирования. Бизнес-аналитик преподносит требования с точки зрения конечного пользователя, системный аналитик — с точки зрения их реализации на выбранной платформе.
Заказать консультацию по бизнес-анализу для вашего программного продукта можно здесь.
От своих специалистов мы ожидаем следующих знаний и компетенций:
Вследствие разделения зон ответственности, системные и бизнес-аналитики оформляют различные наборы документов. В результате работы бизнес-аналитика будет создан Vision and Scope document, обозначающий границы проекта, будут задокументированы бизнес-требования (BRD) и составлены спецификации требований (SRC).
Системный аналитик представит концепцию IT-решения (Software Design Document) с указанием платформы реализации проекта, технологии, в том числе языков программирования, интерфейсов взаимодействия.
На практике четко разграничить роли обоих бывает очень трудно. В зависимости от особенностей проекта они могут пересекаться и взаимодополнять друг друга. Названия должностей сами по себе не важны. Главное, чтобы сотрудники компании понимали, что скрывается за названием должности и к кому обращаться за решением возникшего вопроса.
