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

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

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

По методологии RUP, на примере которой я расскажу о процессе разработки ПО, проектирование состоит из фаз:

1. Inception. Начало. На этой стадии решается вопрос, to be or not to be — стоит ли начинать

2. Elaboration. Уточнение, проектирование. На этой стадии мы проектируем решение, снимаем риски ошибок следующей фазы

3. Construction. Разработка.

4. Transition. Подготовка релизных сборок, документации, развертывание

Рисунок. процесс разработки в методологии Rational Unified Process

Внутри фаз есть итерации, которые команда выпускает, проверяет и так далее по циклу.

В строках на картинке процесса показаны дисциплины:

1. Бизнес–моделирование — определяем, какие бизнес–задачи тех или иных лиц, участвующих в бизнес–процессах, должна автоматизировать система

2. Проработка требований — определяем, ЧТО должна делать система, чтобы реализовать бизнес сценарии пользователей, решить их задачи. На этом уровне сама система рассматривается как черный ящик. «Что» и «Как» — это важный момент, разграничительная линия компетенций.

3. Проектирование системы — фиксируем, КАК должна быть реализована система: модель данных, компоненты системы, протоколы обмена данных, технологии и т.п. На этом уровне система рассматривается как белый ящик.

4. Реализация требований — разработчики пишут код, проектировщики интерфейса создают макеты и т.д.

5. Тестирование. На примере тестирования поясню, что значат «горбы» на диаграмме. Это интенсивность работ. тестирование идет по итерациям, поэтому оно максимально в середине итерации, и спадает к концу итерации. На процессах, не привязанных к итерациям, рост и спад активности привязан к фазам.

6. Развертывание. Определяем, какое количество серверов и других hardware компонент нужно для развертывания системы.

Бизнес аналитик исследует клиентский опыт, описывает текущий (As Is), целевой (To Be) процессы:

Рисунок. Бизнес–процесс на диаграмме, выполненной в нотации BPMN

В процессе работы выявляет и фиксирует, какие бизнес–правила должна выполнять система. Например, федеральный закон ФЗ-152 о персональных данных. Если вы не участвовали в разработке ПО, хочу обратить ваше внимание, что, кроме того, что нужно непосредственно пользователю, например, снять деньги в банкомате, система должна соответствовать вагону требований регуляторов, стандартов хранения данных, подзаконных актов и т.д. Эти требования должен выявить и зафиксировать бизнес–аналитик (БА).

Задача БА — определить концептуальные, высокоуровневые требования к системе, руководствуясь тем, как должны решаться задачи бизнес–пользователей, участвующих в бизнес процессах. В V–модели разработки ПО зона ответственности бизнес аналитика это разработка концепции и технического задания к продукту:

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

Иначе говоря, бизнес аналитику нужно знать бизнес–правила, регламентирующие индустрию работы заказчика Бизнес аналитик должен уметь моделировать бизнес процессы, например, в нотации BPMN, EPC, чтобы наглядно представить модели процессов As Is, To Be.

Поскольку у БА больше компетенций в зоне пользовательского опыта, логичное развитие БА может быть в сторону продакт менеджера (product manager) или владельца продукта (product owner):

БА —> старший БА —> Ведущий БА —>Продакт Менеджер

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

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

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

Для того чтобы описать решение, системному аналитику нужно знание специфики работы на различных платформах, в различных технологиях. Например, разбираться в веб–сервисах, облачных технологиях и т.д. Часто системному аналитику требуется знать SQL, иметь опыт работы с базами данных. Уметь описывать интерфейсы взаимодействия между модулями системы или с внешними сервисами. Т.е. описывать API. API (Application Programming Interface или интерфейс программирования приложений) — это совокупность инструментов и функций в виде интерфейса для создания новых приложений, благодаря которому одна программа будет взаимодействовать с другой.

БА —> старший СА —> Ведущий СА —>Архитектор

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

Я работаю сейчас бизнес аналитиком, именно потому, что я не вижу себя в будущем архитектором. Мне интереснее изучать клиентский опыт, определять бизнес–решение, которое оптимально решит задачи бизнес–пользователей

Если кратко, то:

Бизнес–аналитик – про знание предметной области, общение с заказчиком, постановка задачи черному ящику в формулировке «ЧТО должна делать система».

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

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

При выборе также учитывайте такие факторы:

• Разработчику/тестировщику будет проще освоить специальность именно системного аналитика, потому что СА ближе к нему по компетенциям.

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

• Системному аналитику проще переходить между разными тематиками, иначе говоря, доменами. Если СА знает стек технологий, REST/Soap, может описывать XML, XSD схемы, знает способы интеграции систем, знает SQL, то он может успешно работать в компании из любого домена, где требуются знания этих технологий: гос. услуги, e-commerce

Согласно данным сайта HH, в России за три года произошел рост заработной платы для аналитика DWH c 90 000 рублей до 140 000. Это средняя цифра на рынке труда. Поскольку это диджитал- профессия, то и обучение обычно проходит в онлайн–формате.

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

Существуют некоторые требования к тому, какими знаниями и опытом должен обладать DWH–аналитик, чтобы эффективно выполнять свои обязанности. Рассмотрим их поэтапно по мере становления человека в профессии.

Джун или стажер, или младший специалист.

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

На первой ступени профессии младший специалист должен обладать следующими знаниями и навыками:

• Понимать принципы работы и устройства баз данных.

• Уметь пользоваться инструментами для работы с данными, например, с такими как SQL, Python и Hadoop, а также проводить системный анализ.

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

Мидл или специалист.

Это уже средний уровень владения навыками и знаниями в профессии DWH–аналитика. Обычно, чтобы перейти на следующую карьерную ступень после этой, требуется примерно 3-4 года. Опять же, срок может варьироваться в зависимости от компании. В некоторых случаях можно перескочить быстрее, если опыт был насыщенным и руководство заметило перспективного сотрудника и его усилия.

На данном этапе сотрудник должен соответствовать следующим требованиям:

• Уметь самостоятельно, без надзора руководителя, проводить анализ данных.

• Заниматься разработкой и поддержкой ETL–процессов, чтобы управлять потоками данных.

• Грамотно и оперативно создавать отчеты с помощью инструментов визуализации для бизнес–пользователей на основе полученных из DWH данных.

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

Сеньор или старший/ведущий специалист.

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

Данный уровень подразумевает наличие следующих скиллов:

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

• Владеть необходимыми методами и инструментами для построения архитектуры хранилища данных.

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

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

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

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

DWH–аналитик – это системный аналитик, ориентированный на работу с Data WareHouse системой.

Ниже разберемся, что такое DWH–система и зачем она нужна бизнесу, а также в чем заключается роль DWH–аналитика.

Data WareHouse (DWH) – это тип хранилища, собирающее исторические данные организации из других ее систем. В нем вся информация упорядочивается и систематизируется по каталогам, что в дальнейшем упрощает процесс работы с данными.

Чем же тогда это отличается от СУБД (Системы управления базами данных)? Тем, что DWH–система хранит разные типы данных.

Например, те же СУБД содержат в себе информацию для определенных подсистем. Складская БД хранит данные и процессы, связанные со складом и тем, что на нем происходит. В базе данных кадрового отдела находится информация по персоналу, их уровню образования, компетенции и т.д.

Data WareHouse объединяет данные всех подразделений в одном месте. То есть хранилище будет содержать информацию и о клиентах организации, и товарах, и сотрудниках и т.д.

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

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

Разумеется, существуют и другие причины использования Data WareHouse, но их можно считать ключевыми. Для малого бизнеса DWH–системы не являются обязательными, так как они не обладают таким массивом данных, которые требуют дублирования и дополнительного места для хранения.

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

Тогда Data WareHouse позволяет не просто быстро извлечь данные, необходимые для принятия решений, но и привести их в человеческий вид, то есть сделать более читаемыми и понятными. Это, в свою очередь, позволяет сэкономить и время, и деньги.

Теперь разберемся, в чем заключается роль DWH–аналитика при работе с системой хранения.

Хороший аналитик по работе с Data WareHouse может оптимизировать работу компании за счет умелой операции с бизнес–данными. Кроме того, для этого ему нужно быть экспертом в той области, в которой он осуществляет анализ данных. То есть случайный человек вряд ли сможет занять эту должность в компании.

На DWH–аналитика также высок спрос на рынке труда, как и на бизнес–аналитиков или системных аналитиков, так как современному бизнесу приходится работать с большим объемом информации. Причем он постоянно растет, и совсем неважно, какой именно это тип данных, будь то контактные данные новых клиентов или налоговая декларация.

Главной задачей аналитика DWH является работа с полученными данными из других БД. Ему необходимо уметь:

• Осуществлять сбор данных, извлекать их, проводить анализ и грамотно использовать их для DWH–хранилищ;

• Находить скрытые потребности организации в данных DWH, а затем грамотно распределять их в системе;

• Заниматься подготовкой отчетов по запросу от вышестоящего руководства;

• Регулярно проверять целостность и сохранность DWH–баз;

• Уметь работать со специальным ПО для DWH–баз, а также знать необходимые для этого языки программирования;

• Приводить отчеты к более «человеческому» виду, то есть делать их более доступными для понимания людям, которые не являются профессионалами в аналитике. Для этого аналитику необходимо использовать инструменты визуализации, которые превратят кипы текста в графики и диаграммы;

• Знать и использовать современные методики и инструменты описания бизнес–процессов.

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

В диджитал–сфере существует множество типов аналитиков, которые работают с тем или иным типом данных. Они имеют разные задачи, но можно ли одного заменить другим?

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

Бизнес–аналитика.

В данном случае под этим термином подразумевается процесс анализа данных, которые заранее уже были собраны, обработаны и подготовлены к исследованию и оценке специалистами. Обычно для этого используются Business Intelligence (BI) – набор инструментов и методов, помогающих свести всю бизнес–информацию из разных источников в единую систему. Она–то в конечном итоге и подвергается анализу.

Для автоматизации процессов используют различные сервисы и софт, их ещё называют BI–системами. Среди них такие, как Microsoft Power BI, Zoomdata, Information Builders и множество других аналогов со схожим функционалом. Обычно эти инструменты обладают опциями, которые позволяют систематизировать и визуализировать данные. Это необходимо для того, чтобы сделать результаты аналитики доступными для понимания не только для специалистов, но и для других участников бизнес–процессов.

В каких случаях необходимо проводить сбор и анализ бизнес–данных?

• Возникла потребность в систематизации бизнес–данных, собранных из разных источников.

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

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

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

• Для оптимизации процессов требуется всесторонний мониторинг бизнес–системы.

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

Продуктовая аналитика.

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

Часто продуктовую аналитику относят к бизнес–аналитике, но это несколько разная история, скорее частный случай. Рассматривается не весь бизнес в целом, а его отдельный товар или услуга.

Когда требуется использовать продуктовую аналитику?

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

• Пользователи продукта проявляют интерес, но не совершают целевые действия, то есть покупку товаров или услуг.

• Требуется краткий срез метрики эффективности продукта, чтобы принять управленческие решения.

• Имеются продуктовые гипотезы, требующие проверки на основе реальных цифр и данных.

• Результаты А/В–тестов не обладали должной прозрачностью, поэтому требуется уточнение данных.

Мобильная аналитика.

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

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

Когда используют мобильную аналитику?

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

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

Предиктивная аналитика.

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

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

Для создания адекватной модели требуются внутренние и внешние данные о бизнесе и сфере деятельности.

Метод предиктивной аналитики необходим в таких случаях, как:

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

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

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

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

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

• Для составления прогноза эффективности рекламного контента и маркетинговых активности.

• Есть потребность предсказывать и влиять на LTV клиента.

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

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

Сквозная аналитика.

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

Когда используют сквозную аналитику?

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

• Нет понимания, какие маркетинговые активности по–настоящему эффективны.

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

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

• Надоело делать ошибки в стратегии продвижения и сливать впустую бюджет.

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