Ложь, статистика и бизнес-анализ (в ИТ)

Давайте посмотрим, кто такой бизнес-аналитик (сначала не в ИТ, потом в ИТ), чего от него ждут, чем он должен заниматься и что он делает на самом деле.

Если исходить из такого красивого и амбициозного названия, он изучает, исследует и анализирует бизнес (оценивает, сравнивает, категоризирует, устанавливает связи).

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

Что в себя включает бизнес, какие аспекты?

Практически в любом бизнесе так или иначе есть эти штуки.

IIBA презентует нам профессионала — бизнес-аналитика, ни много ни мало, как профессионала по развитию бизнеса:

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

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

(NB: оцените, как какая-то добрая душа в 2017-м году заменила в русской википедии слово «низшая» на «высшая»)

Учитывая громадный объём информации о бизнесе, понятно, что каждый такой бизнес-аналитик, как дотошный муравьишка, изучает не весь бизнес (слона) целиком, а только лишь какой-то его аспект (уши, хвост) в какой-то части.

Т.е. на практике такие люди по сути занимаются изучением фрагмента, аспекта бизнеса. А не бизнеса целиком. Они не способны говорить про бизнес целиком, потому что у них для этого нет данных и, зачастую, кругозора (знания того, как работают бизнесы, хотя бы в объёме MiniMBA или опыта своего бизнеса).

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

Также внутри или снаружи бизнеса они могут фокусироваться на каком-то типовом аспекте бизнеса, например:

В ходе анализа бизнеса целиком и проектирования его развития руководители с помощью архитекторов предприятия и консультантов принимают решения различного рода:

И только в случае возникновения решений про автоматизацию они пойдут к ИТ-подрядчикам и их аналитикам.

Опять же если пользоваться анализом слов, то получается, что эти аналитики изучают ИТ-бизнес. Например, IT Business Analyst в EPAM или DataArt вроде бы должен изучать то, как именно устроен бизнес по оказанию услуг в этих компаниях.

Но судя по текстам вакансий и прочей информации, они всё-таки работают с клиентами, а не с собственной компанией как объектом изучения и изменения.

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

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

Это в идеале.

А на самом деле может оказаться, что существующие и целевые модели деятельности заказаны именно компании-консультанту, которая специализируется на нужном клиенту сегменте бизнеса и разбираётся в нём на голову выше клиента и уж тем более ИТ-подрядчика, мастера на все руки, любителя слов AWS, Azure, DevOps, CI/CD, а не слов из бизнеса клиента.

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

Тогда более точное название такой роли будет Business Operations Automation Analyst, если он заодно владеет каким-то движком/инструментом для автоматизации, то Business Operations Automation Engineer.

А никак не IT Business Analyst, который сбивает с толку.

Слово Business Operations важно ещё для того, чтобы отделять специалистов по автоматизации обработки бизнес-информации от специалистов по автоматизации, например, производства — станков, добывающих и перерабатывающих линий и т.д.

См. Industrial Systems Automation Engineer

Другая понятная часть истории заключается в том, что мало кому (заказчику, пользователям, архитектору, руководителю разработки) нужны результаты анализов сами по себе — оценки, категоризации, связи, классификация.

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

Поэтому слово Analyst к сожалению скрывает за собой большУю и важнейшую часть работы — синтез, проектирование, конструирование.

Хорошие бизнес-требования являются отличной отправной точкой для проектирования. Но, во-первых, их логичнее ждать от аналитика со стороны заказчика, во-вторых, от них довольно далеко до пресловутых «тикетов для разрабов».

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

Давайте посмотрим, что же делает пресловутый «бизнес-аналитик в ИТ» на самом деле:

И много ли в этой работе анализа бизнеса? По мне так не очень. Поэтому название крайне неудачное.

Хотя бы Business Operations Automation Designer звучит точнее.

Проектировщик автоматизации деятельности предприятия. Почти проектировщик автоматизированных информационных систем (предприятия) — незаслуженно забыта фраза.