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