Сегодня рассматриваем виды бизнес-требований, их взаимосвязи и подход, который помогает удерживать контур проекта и фокусироваться на целях. Еще больше о нюансах работы аналитика – на бесплатном мастер-классе 7 мая, присоединяйтесь!
ИТ-проекты часто направлены на автоматизацию каких-то задач пользователей. Для чего мы этим занимаемся – чтобы компания, в которой эти люди работают, развивалась и приносила больший доход. А для этого приходится разбираться в специфике бизнеса и отрасли, которую вы автоматизируете.
Работа над проектом начинается с целей бизнеса и бизнес-требований. Все пользовательские и системные требования необходимо рассматривать с точки зрения этих целей. Иначе содержание и бюджет вашего проекта может неконтролируемо расти или превратиться в бесконечные доработки. Именно с этой проблемой команды чаще всего сталкиваются на практике: требования растут, контур проекта размывается, результат не совпадает с ожиданиями бизнеса.
В этой статье я помогу разобраться с тем, как подойти к решению данной задачи. Поговорим о том, какие задачи должны выполнять аналитики при работе с требованиями, с какими видами требований приходится работать и с каких нужно начинать. Более подробно о том, как структурировать требования и удерживать контур проекта, расскажу на бесплатном мастер-классе 7 мая.
Виды ИТ-аналитиков и их работа с требованиями
В ИТ-сообществе по-прежнему нет четкого понимания, какие бывают аналитики, чем они отличаются и как работают с требованиями. Это можно заметить в содержании профессиональных стандартов и описаниях вакансий. Остается актуальным и вопрос, что первично при внедрении автоматизации: ИТ-система или специфика конкретного бизнеса.
Попробуем кратко определить суть разных видов аналитиков. Я выделяю три ключевые роли:
- Бизнес-аналитик переводит требования бизнеса в требования к системе, отвечает на вопрос, что и зачем нужно автоматизировать.
- ИТ-аналитик переводит бизнес-требования в технические требования. Без привязки к конкретной системе, в которой эти требования предполагается реализовывать.
- Системный аналитик адаптирует требования к конкретной системе, предлагает решение, как лучше использовать ее функционал для удовлетворения потребностей пользователей.
Таким образом, в ИТ-проектах основную роль играет ИТ-аналитик, который является проводником между интересами бизнеса и возможностями конкретного программного продукта.
Ответ на вопрос, что важнее, система или специфика бизнеса, очевиден. Заказчик, принимая решение о разработке собственной или внедрении типовой ИТ-системы, хочет не «что-то автоматизировать», а решить конкретные боли конкретной компании. И как правило, эти боли связаны с бизнес-эффективностью, а не с отсутствием ИТ-системы. Она выступает как инструмент, позволяющий эту самую бизнес-эффективность повысить быстрее и качественнее.
А это означает, что ИТ-аналитик должен довольно хорошо понимать не только техническую сторону (средства автоматизации и цифровизации, способы интеграции и пр.), но и разбираться в бизнес-специфике. Уметь предлагать оптимальные способы реализации требований бизнеса.
Что такое бизнес-требования и чем они отличаются от других видов требований
Если рассмотреть работу с требованиями как бизнес-процесс, то укрупненно его можно представить примерно так.
Это моя авторская схема, которая показывает, как распределяются роли аналитиков в процессе работы с бизнесом: от определения стратегии до ее воплощения в конкретных инструментах.
Схема немного упрощенная, из нее осознанно вынесен вовне процесс работы с бизнес-изменениями, хотя мы все понимаем, что внедрение ИТ-инструментов тесно связано с ними. Также не детализированы процессы выбора ИТ-решения, разработки, тестирования и внедрения, поскольку они не относятся к основному процессу работы с требованиями.
Эта модель показывает разделение зон влияния между разными типами аналитиков и зоны явных пересечений этих ролей. И определяет начальную точку – выявление бизнес-целей и определение бизнес-требований.
Что из этого следует? То, что владелец или руководитель бизнеса (а не владелец процесса и уж тем более не рядовой пользователь) является заказчиком автоматизации. Именно он платит деньги. И он хочет понимать:
- на что он выделяет существенные бюджеты и какую практическую пользу получит его бизнес, вложив эти средства в ИТ;
- зачем ему вообще выходить из зоны комфорта, если у него и так все неплохо работает.
Давайте разберемся, какие виды требований бывают, и как они между собой связаны. Для этого существует известная многим модель Вигерса.
Эта модель описывает виды требований, проводит их декомпозицию от стратегии к реализации, показывает связи и влияние разных видов требований друг на друга.
Вариантов представления модели Вигерса довольно много. Но мне больше всего нравится эта схема, немного уточненная и дополненная с учетом экспертного опыта. Она наглядно показывает: то, что аналитики привыкли называть «ТЗ» и даже «функциональные требования», является производным от бизнес-требований. Сами же бизнес-требования – это способ реализации стратегии и целей бизнеса, они исходят из них, а не живут сами по себе.
Если мы теперь попробуем наложить модель Вигерса на процесс работы аналитика, получится примерно такая картинка.
В процессе реализации требований аналитик должен регулярно сопоставлять требования нижнего уровня требованиями верхнего уровня.
Как правильно определять бизнес-требования
На формулировании бизнес-требований обычно спотыкаются не только начинающие аналитики, но и довольно опытные архитекторы и руководители проектов. Приведу пару примеров, как правильно сформулировать требования с позиции бизнеса и что бизнес-требованиями не является.
Пример 1
«Цель проекта – перейти на современную ИТ-систему», говорит вам заказчик. Знакомо, не правда ли?
Понимаете ли вы из такой формулировки, как ваша ИТ-система поможет достичь целей бизнеса? Какими критериями заказчик будет оценивать успешность тех проектных решений, которые вы ему предложите?
Попробуем перефразировать: «Нам необходимо снизить стоимость владения ИС на 30% за 5 лет за счет перехода на широко используемые и постоянно развивающиеся ИТ-решения». Лучше, не правда ли?
Пример 2
Заказчик, запрашивая автоматизацию продаж, говорит вам: «Цель – повысить эффективность продаж за счет автоматизации». А если на эффективность его продаж влияет высокая конкуренция, территориальная удаленность клиентов и другие внешние факторы, и это все вообще никак не связано с отсутствием или наличием ИТ-системы?
Попробуем переформулировать требование, например, так: «Обеспечить расширение сети магазинов (прирост на 10 в год) за счет создания тиражного ИТ-решения управления розницей». Сразу становится понятно, какой конкретно цели в части продаж должна помочь достичь будущая ИТ-система. Самое главное, что это вполне реалистичная цель и адекватный способ ее достижения в контексте ИТ.
Вывод: для начала аналитику нужно научиться, а затем помочь заказчику правильно формулировать бизнес-требования. Есть несколько критериев, каким должно быть хорошее требование:
- Направлено на удовлетворение определенной потребности бизнеса (боль, проблема или возможность), отвечает на вопрос «для чего?» (нам нужна ИС, продукт).
- Связано с бизнес-целями, показателями эффективности/результативности компании или отдельных бизнес-процессов, зачастую имеет измеряемые метрики.
- Определяет ценность автоматизации для бизнеса (коммерческую ценность, влияние на финансовый результат).
- Имеет однозначное (четко формулируемое, не абстрактное) толкование.
- Может включать в себя пути достижения желаемого состояния, отвечать на вопрос, за счет чего мы будем реализовывать это требование.
- Всегда не зависит от продукта – не описывает функции или свойства конкретного продукта, решения, которые должны быть применены.
«Слепые зоны» требований: что может увидеть аналитик и почему это важно при автоматизации
Мы все привыкли оперировать абстрактным понятием «ИТ-требования» или «требования к системе». Но если вникнуть глубже, то огромное количество требований, которые так или иначе влияют на конечный ИТ-продукт, не являются «функциональными» в прямом смысле и даже не являются требованиями к ИТ-системе.
Именно такие «скрытые» требования чаще всего приводят к срыву сроков и бюджета. Аналитику важно уметь их выявлять и связывать с бизнес-процессами – этот вопрос также разберем на мастер-классе.
Виды требований с точки зрения содержания
|
Требования к интерфейсам |
|
|
Требования к отчетам |
|
|
Требования к нормативно-справочной информации (НСИ) |
|
|
Требования к интеграции |
|
|
Требования к специальному оборудованию |
|
|
Технологические требования |
|
Самое главное – все эти виды требований еще и влияют друг на друга. Схема влияния выглядит следующим образом.
Оказывается, требования к отчетам напрямую влияют на ИТ-инфраструктуру. Если заказчик хочет видеть все графики в режиме онлайн на планшете, находясь «в отпуске на Канарах», отсюда произрастают требования к платформе, серверам и каналам связи.
Но и это еще не все. Если мы вспомним модель Вигерса, то есть еще бизнес-правила.
Носители бизнес-правил в компании
|
Учетные политики |
|
|
Положения и регламенты |
|
|
Показатели и правила контроля |
|
Бизнес-правила тесно связаны с бизнес-требованиями, хотя ими и не являются. Например, та же учетная политика завода создана не просто так – она призвана обеспечивать мониторинг и достижение целевых бизнес-показателей по объемам производства, допустимому браку, простоям и т.п.
Эти правила являются «законодателем» по отношению к функциональным требованиям. Они задают ограничения того, по каким правилам должна работать система.
Вся эта информация – тоже часть работы аналитика. Но без изучения этих требований вы не сможете грамотно спроектировать и внедрить систему, которая отвечала бы потребностям вашего заказчика.
Что же делать, если вы не знаете специфику конкретного бизнеса (а, как правило, ни один, даже профессиональный аналитик ее не знает, т. к. он работает с разными видами бизнеса)? Нам на помощь приходит процессный подход. Именно умение видеть бизнес через бизнес-процессы и их связи помогает аналитику быстро погрузиться в содержание работы компании и не упустить важные детали.
Если нужно системно освоить этот подход, для этого подойдет онлайн-курс «Процессный подход в проектах внедрения ERP-систем», который стартует 18 мая. С помощью авторской методики разберем, как определить контур автоматизации, собрать полные требования без «неучтенки» и связать их с бизнес-процессами и целями.
Еще больше о работе с требованиями – на мастер-классе
Мастер-класс «Работа с требованиями в комплексных проектах автоматизации: как избежать "неучтенки"»
Дата и время: 7 мая в 13:00 (МСК).
Формат: онлайн, бесплатно, нужна регистрация.
На вебинаре мы поговорим о том:
- как правильно определять количество и виды бизнес-процессов в вашем контуре, связывать требования с автоматизируемым процессом;
- какие еще требования, кроме функциональных, важно уметь выявлять и учитывать при автоматизации;
- как удерживать контур проекта и при этом удовлетворять начальные требования заказчика.
