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

Вот 4 причины, почему он окупается быстрее, чем вы думаете:

1. Наглядность (увидеть узкое место). Объяснить проблему на словах это как описать вкус умами: вроде базовый вкус, но восприятие у каждого своё. На BPMN-модели узкое место видно сразу: вот здесь теряется время, вот тут дублируются данные. Один раз нарисовали и вся команда видит картину целиком. 2. Обучение без «А он мне не передал». Надеяться, что увольняющийся сотрудник передаст все дела это лотерея, особенно на текущем рынке. Намного стабильнее, когда есть модель процесса и понятная инструкция. Новый человек садится, читает и включается в работу за дни, а не за месяцы. Знания остаются в компании, а не в чьей-то голове. 3. Однозначность (меньше итераций). Плохое ТЗ — это когда разработчик сделал «как понял», а заказчик говорит: «Я не это имел в виду». Чёткие ФТ и ТЗ уменьшают количество правок. Процесс доработок становится быстрее, а бюджет не сгорает на бесконечных переделках. А также всегда видно, где процесс хромает и кто против автоматизации. 4. Коммуникация (и общий язык). Во-первых, через аналитика бизнесу легче общаться с IT: он переводит с человеческого на технический и обратно. Во-вторых, аналитик ведёт wiki компании и словарь терминов. Чтобы не было ситуаций, когда одни говорят «компьютерщики», другие «программисты», а третьи «разработчики» и каждый понимает под этим что-то своё. Единый глоссарий повышает общую культуру и зрелость компании. Итог: Бизнес-аналитик — это не лишняя роль. Это человек, который сэкономит ваши деньги на дистанции, сохранит знания и построит мост между бизнесом и разработкой. Он нужен, но не все это понимают.

Коллеги-аналитики, а что бы вы добавили в этот список? Какие задачи критически важны, но о них часто забывают?