Что такое бизнес-анализ в ИТ и чем он отличается от сбора требований

Зачем бизнес-анализ

Бизнес-анализ отвечает на вопрос, который в ИТ задают слишком поздно: какую задачу бизнеса мы решаем и стоит ли решать её так. ПрактикаПрактикаНабор ресурсов организации для выполнения работы определённого типа.ITIL 4 разбирает потребность и предлагает решение, а не принимает заказ на систему.

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

Отсюда самое частое искажение практики. Аналитик, который записывает пожелания и передаёт их разработчику, работает переводчиком. Движение идёт в другую сторону: практика перестаёт быть переводчиком между техническими и бизнес-командами и встраивается в работу самого бизнеса 1.

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

Когда практика работает

Три вопроса, ответы на которые слышны на первой же встрече по новой задаче.

Разговор начинается с задачи, а не с системы. Как проверить: в постановке сформулировано, что не получается у бизнеса сейчас, а не какую кнопку добавить.

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

Требования дошли до исполнителей в рабочем виде. Как проверить: команда получила функциональные и нефункциональные требования с приоритетами и сведения об обстановке, где решение будет работать 1.

Что входит и что рядом

Аналитик как источник знания о требованиях

Определение роли неожиданно сильное: аналитик должен быть основным источником знаний по любым вопросам о требованиях на всём протяжении жизни решения — независимо от того, какими методами оно разрабатывается и поставляется 1.

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

Второе следствие — про гибкие команды. В них практика перестаёт быть отдельной должностью и становится постоянной работой владельца продукта или услуги 1. Знание о требованиях при этом никуда не девается: меняется только то, кто его держит.

Что на входе и что на выходе

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

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

Два получателя результата

ITIL разводит их прямо, и разница объясняет, почему один документ не годится обоим 1.

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

Как это работает

Работа делится надвое: наладить сам подход к анализу — и провести разбор конкретной потребности 1.

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

Две строки этой таблицы стоит развернуть.

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

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

Модели, которыми работают

ITIL называет анализ интеллектуальной дисциплиной и перечисляет виды моделей, которыми аналитик разбирает предмет: понятия, данные, решения, организации, процессы, границы и состояния 1. Через них он делает три работы 1:

• собирает у заинтересованных цели, требования и ограничения;
• даёт этим людям сведения, нужные им для их собственной работы;
• превращает потребности во внятно сформулированные требования.

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

Что с чем путают

Бизнес-анализ и сбор требований. Сбор — часть работы. Анализ начинается там, где выясняется, что за просьбой «добавьте кнопку» стоит потребность, закрываемая иначе и дешевле.

Бизнес-анализ и проектирование услуги. Анализ отвечает, какую потребность закрываем и почему выбран этот путь; проектирование — как устроена услуга, которая его реализует. Это разные практики, и их положено согласовывать 3.

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

Аналитик и посредник. Роль переводчика между бизнесом и ИТ — предыдущее состояние практики; дальше идёт переход к работе, встроенной в бизнес 1.

Кто участвует

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

Как измерять

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

Зрелость бизнес-анализа

✕

Где ломается чаще всего

Шесть мест, в порядке частоты.

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

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

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

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

Один подход на все задачи. Разбор мелкой доработки идёт тем же путём, что запуск новой услуги.

Анализ оторван от денег. Предложение не связано с бюджетом и сроками, и разговор о выборе превращается в спор о вкусах.

Что говорят своды

69Своды знаний и стандарты — разобраны отдельноЧем ITIL отличается от COBIT и ISO, что из этого обязательно, а что на выбор, и где брать первоисточник. У каждого свода отмечено, развивается он или давно заморожен, и есть ли действующий ГОСТ. По 51 практикам из 62 проставлено соответствие COBIT.Открыть →

ITIL держит бизнес-анализ отдельной практикой, строит её вокруг потребностей и решений и описывает переход от роли переводчика к работе, встроенной в бизнес 1.

COBIT выделяет определение требований отдельной целью управленияЦель управленияЕдиница описания COBIT: цель с проверяемым содержанием, у которой есть процесс того же имени.COBIT 2019, книга Governance and Management Objectives, отдельно от разработки решений 4.

ГОСТ Р ИСО/МЭК 20000-1 отдельного процесса не содержит: требования к сервисам появляются при планировании, а проектирование опирается на документированные требования 2.

MOF подходит с другой стороны: он спрашивает, разбирают ли спрос на ИТ-услуги и оценивают ли его и организована ли работа с новыми бизнес-запросами — приём, упорядочение, обработка 5.

Расхождение по существу здесь одно: ITIL считает анализ самостоятельной работой, а стандарт растворяет его в планировании сервисов. Для небольшой организации второе честнее — там анализ ведёт тот же человек, что и планирование. Как только заказчиков и услуг становится много, работа отделяется сама.

Где описано

Что почитать дальше

Три соседние практики, между которыми живёт анализ: SDSПроектирование услуги — как потребность превращается в замысел услуги, PRTУправление портфелем — где решают, что брать в работу, RELУправление отношениями — откуда приходит понимание заказчика.