Кто такой Бизнес-Аналитик? - Курилка

**George Nordic** · 03.10.2014, 17:31

Недавно отвечал на вопрос "Кто такой бизнес-аналитик и в чем состоят его должностные обязанности". Вот что получилось в итоге.

Бизнес-аналитик - это переводчик с языка бизнеса в техническое задание для ИТ-специалистов. У бизнес-заказчика есть ряд задач: надо выявить ряд проблем и дать ответ на вопросы "почему так произошло" и "что делать дальше":
* почему упали продажи по группе товаров
* какой из товаров не продается
* у кого подходит окончание срока годности
* сколько ДС заморожено у нас в запасах
* как скорректировать ассортимент
* как построить более-менее точный прогноз
* "а что-будет если" и т.д

Причем ряд задач ставиться очень быстро и требует незамедлительного реагирования - "срочно подготовьте отчет по должникам с долгом более 30 дней от даты оплаты согласно договору" (при этом кроме даты выставления счета надо смотреть и на условия оплаты как по счету, так и в соответствии с договором по контрагенту), "давайте посмотрим на платежный календарь и выявим cashflow разрывы на завтрашнем совещании". У ИТ-подразделения, к сожалению, совсем другие приоритеты - 95% задач лежат вокруг инфраструктуры: лишь бы почта ходила да принтеры печатали, и 1С не висла. (об этом я писал в отдельной статье)
А пока все работает - можно и в танчики поиграть, или поглумиться в своей среде над "юзверями", а если разработка - как увлекательно построить свой велосипед!!! Нужен он бизнесу или нет - другой вопрос. Саморазвитие - тоже важная черта. И если бизнес ставит задачу ИТ напрямую, то это зачастую вызывает муки и непонимание у ИТ - чего они от него хотят и почему он срочно должен все бросать и что-то делать? "Скажу - сделаем послезавтра, подождут, не впервой, все равно никто не проверит".

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

Иногда под БА требуют постановщика задач в более широком смысле - он должен анализировать цепочки требований не только от бизнеса к ит, но и от бизнес-подразделения к бизнес-подразделению, и оптимизировать прохождение подобных запросов: то, что называется модным (до сих пор, кстати, модным) термином "оптимизация бизнес-процессов". Так что искать должностные инструкции для бизнес - аналитика необходимо именно от бизнес-заказчиков, они точно понимают, кто им нужен.

Где искать? Например, на hh.ru - с первого раза удалось найти вполне адекватное описание требований к бизнес аналитику:

Цитата:

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

Требования:
* Высшее образование (техническое, математическое, прикладная математика);
* Опыт работы от 2-х лет в какой-то из областей:
постановка задач по автоматизации учета на уровне технических заданий,
описание и автоматизация бизнес-процессов компании,
разработка стандартов, регламентов, инструкций и т. п.,
проектирование информационных систем.
* Знание принципов разработки бизнес-процессов в области бюджетирования, управленческого учета и бюджетного управления
* Знание принципов разработки регламентирующих документов;
* Знание MS office, ARIS, BPWin, MS Visio или другое средство моделирования бизнес-процессов.

Я опубликовал в блоге, но получил предложение обсудить это в "Курилке", что и делаю.

С Уважением,
Георгий

zemlyn · 03.10.2014, 18:47

а еще есть системный аналитик

**George Nordic** · 06.10.2014, 13:44

Цитата:

Сообщение от zemlyn

а еще есть системный аналитик

zemlyn, спасибо за дельное замечание.

Итак, получается есть 3 специальности со схожими названиями.

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

2. Бизнес-аналитик (применительно к ИТ)
Основной задачей Бизнес-Аналитика (БА) является предоставление точной, своевременной и непротиворечивой информации о состоянии бизнеса и окружающей среды для лиц, принимающих решения, с целью принятия верных и обоснованных управленческих решений.
Так же важной задачей БА является разработка или поддержка ключевых показателей, сводных показателей и карт сводных показателей, и самое, наверное, сложное - это построение системы сбалансированных показателей. На основании текущих значений показателей бизнес может выявить проблему, в т.ч. путем доступа к детализированной информации, запросов к данных, выборок, наложением произвольных фильтров, исторического, геоинформационного, set / like и др. анализов, сделать и проверить ряд гипотез (what-if анализ, прогнозирование), принять меры по исправлению ситуации и/или скорректировать стратегию - что также надо отразить в системе показателей и отслеживать исполнение данной стратегии. Так как данные зачастую хранятся во множестве ит-систем, данная специальность подразумевает не только понимание задач бизнеса, но и знание структуры данных или умение поставить задачу системным аналитикам или ИТ-специалистам получить ту или иную модель данных или выборку, и оценить ее качество (чистоту данных, возможную ошибку, стоимость ошибки в итоговом отчете и прогнозе). Минимум что для этого надо - уметь работать с отчетами из ERP и "подгружать" туда данные из сторонних систем, что, разумеется, всем нам не в новинку. Осталась более продвинуты стадии, связанные с автоматизированным сбором данных или построением интегрированной шины данных (ETL), процессами, отвечающими за качество данных (DQ) или построением системы управления мастер-данными (MDM), или построением отдельного хранилища данных (Datamart), в которое консолидируются данные, предназначенные для аналитики из множества систем, очищенные и пригодные к использованию, или тоже самое, но с хранением истории (DWH). В каждую из этих областей можно развиваться, и везде есть интерес и рост интереса - это связанно в первую очередь с ростом данных, и, во-вторую, с решением задач по учету данных. Данные есть, пора с ними что-то делать.

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

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

С Уважением,
Георгий

ppson · 06.10.2014, 14:37

Цитата:

Сообщение от zemlyn

а еще есть системный аналитик

есть еще и менеджера по продажам, применительно к ИТ.

**George Nordic** · 06.10.2014, 15:14

Цитата:

Сообщение от ppson

есть еще и менеджера по продажам, применительно к ИТ.

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

С Уважением,
Георгий

AlexeyS · 06.10.2014, 15:28

Профессиональные стандарты в области ИТ
http://www.apkit.ru/committees/educa.../standarts.php

Архитектор программного обеспечения
Программист
Руководитель проектов в области информационных технологий
Системный аналитик
etc...

описано вполне подробно

vkofanov · 06.10.2014, 15:47

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

Сразу вспомнился анекдот..
Когда я сюда пришел, один врач сказал, что у меня аппендицит, второй - камни в почках, третий, что порок сердца. - Ну и чем кончилось? - Они вырезали у меня гланды.

vaavr · 06.10.2014, 17:03

Похоже есть две трактовки понятия "бизгес - аналитик" - БА в узком и широком смысле. В узком смысле это, как справедливо замечено: "...это переводчик с языка бизнеса в техническое задание для ИТ-специалистов". В широком смысле это специалист по построению архитектуры бизнеса, обладающий уникальными знаниями методологии оценки влияния ИТ на основные бизнес - цели компании (не "на пальцах"!). В иерархии специалистов это "правая рука" Генерального, с которым он собственно и выстраивает весь бизнес компании, одновременно и автоматизируя этот бизнес.

zemlyn · 13.10.2014, 02:46

Цитата:

Сообщение от ppson

есть еще и менеджера по продажам, применительно к ИТ.

не, в рамках этой темы сейчас в тренде - Product manager

zemlyn · 13.10.2014, 02:51

Цитата:

Сообщение от George Nordic

про бизнес-аналитику, а так же то с ней тесно связано - интеграция, сбор и чистка данных, построение хранилищ

а разве это не datawarehouse developer делает?

**George Nordic** · 13.10.2014, 15:01

Цитата:

Сообщение от zemlyn

а разве это не datawarehouse developer делает?

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

С Уважением,
Георгий

ax_mct · 17.10.2014, 01:02

Цитата:

Постановка технических заданий разработчикам;

И что действительно бизнес-аналитик/системный аналитик ставит (или должен ставить) технические задания разработчикам?

Упаси боже от такого счастья. Слово "техническое" явно лишнее. И наличии такого в описании вакансии - неуместно для роли.

FSD/FRD более уместно. Но никак не TSD/TRD

Есть разница между функциональной и технической спецификацией/документом/задачей.
Можно обойтись без технической, документируя после, но результатом работы "первой прокладки" обязан быть функциональный документ. Но никак не технический.

https://ru.wikipedia.org/wiki/Функци...фикация

Цитата:

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

Пример из типичной функциональной спецификации:

Когда пользователь нажимает кнопку ОК, окно диалога закрывается и в фокусе оказывается главное окно, которое было до появления диалога.

ax_mct · 17.10.2014, 01:07

https://ru.wikipedia.org/wiki/Бизнес-аналитик

Цитата:

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

Цитата:

Нельзя путать бизнес-аналитика с «Системным аналитиком» (СА, технический руководитель, системный архитектор, технический лидер и т.д.). Иногда СА называют Business Systems Analyst (BSA). В принципе, эти две должности - очень тесно работающее звено, а для IT – вообще как разные стороны одной монеты. Но даже для IT-сегмента их компетенции пересекаются максимум на 30%.

В принципе в некоторых реализациях роли "системный аналитик" может ставить технические задания.
Но никак не бизнес-аналитик.
https://ru.wikipedia.org/wiki/Системный_аналитик

P.S. Я понимаю что Wiki это забор и никак не истина, но я согласен с тем что в этих статьях там написано по теме.

twilight · 17.10.2014, 02:12

Цитата:

Сообщение от ax_mct

Когда пользователь нажимает кнопку ОК, окно диалога закрывается и в фокусе оказывается главное окно, которое было до появления диалога.

Хм, я бы сказал, что это пример как не надо писать спецификации )

S.Kuskov · 17.10.2014, 07:40

Цитата:

Сообщение от twilight

Хм, я бы сказал, что это пример как не надо писать спецификации )

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

Но мысль ax_mct мне понятна. Возможно это вопрос терминологии, но ведь и вся эта тема об этом.

ax_mct · 17.10.2014, 15:25

Цитата:

Сообщение от twilight

Хм, я бы сказал, что это пример как не надо писать спецификации )

В случае UI, когда с системой взаимодействуют через UI,
функциональная спецификация должна описывать процесс и требования в терминах UI. В основном через use/user cases/scenarios и возможно test scenarios.

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

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

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

Лично я предпочитаю глупейшее описание в терминах UI чем неадекватное и ненужное перечисление технических деталей от лица полных в этом неспециалистов.

И речь не о том что я не знаю UI, вопрос в том как его знают постановщики задач.
При том что техническую часть должны определять специалисты.

Та практика при которой аналитики/консультанты/первая прокладка потеют и составляют псевдо технические документы в ущерб функциональному описанию - порочна.

Bobkov · 20.10.2014, 12:11

Цитата:

Сообщение от ax_mct

В случае UI, когда с системой взаимодействуют через UI,
функциональная спецификация должна описывать процесс и требования в терминах UI. В основном через use/user cases/scenarios и возможно test scenarios.
Беда, когда не понимают сути документов и используют недофунциональные и недотехнические документы ради красивого но бестолкового документа.

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

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

В России, документ, который это описывает, действительно называется "Техническое задание на создание (развитие или модернизацию) автоматизированной системы". Так уж исторически сложилось

Если интересно, содержание этого документа раскрывает ГОСТ 34.602-89 - http://prj-exp.ru/gost/gost_34-602-89.php.

ax_mct · 21.10.2014, 21:06

Цитата:

Сообщение от Bobkov

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

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

В России, документ, который это описывает, действительно называется "Техническое задание на создание (развитие или модернизацию) автоматизированной системы". Так уж исторически сложилось

Если интересно, содержание этого документа раскрывает ГОСТ 34.602-89 - http://prj-exp.ru/gost/gost_34-602-89.php.

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы (пример) - http://prj-exp.ru/patterns/pattern_tech_task.php
Ужос

. Устарело на 20-30 лет. Хорошо для общения между юрлицами, но никак не для человеков на проекте когда роль-человек ставит задачу другой роли-человеку.

Хабрахабр "Документирование по ГОСТ 34* — это просто"
http://habrahabr.ru/post/122700/

Цитата:

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

Действующий ГОСТ 34.602-89 (1990 года) какой-то безлюдный, больше для введения перфокарты годиться или для того чтобы от заказчика отмахаться.

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

ISO/TS 10303-1616:2006
http://www.iso.org/iso/home/store/ca...csnumber=42394

Цитата:

ISO/TS 10303-1616:2006 specifies the application module for AP210 functional specification.

ISO/TS 10303-1616:2006 deals with the representation of functional specification. This data provides information sufficient to allow communication of the behavioural specification of product functions. Formal encapsulation of external data type definitions is made for parametric data and signal characterization. Configuration management information and design change management information is provided.

The following is within the scope of ISO/TS 10303-1616:2006:

behavioural specification of a functional unit based on observed signals within a functional testbench.

Денег правда стоит

но хоть что-то в 2012 году

.

Но это оффтоп по сути. Очевидно же что тех.задание это одно а спецификации это другое.

На данный момент действующий ГОСТ 1992 года
РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов.
http://www.rugost.com/index.php?opti...d=22&Itemid=53

Но он тоже устарел как минимум лет на 30. То есть для создания терминала внесения платежей он подойдет, но не для информационной системы предприятия.