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

Почему проекты «расползаются» по требованиям и как этого избежать? Разбираем пошаговый переход от бизнес-требований к системным через призму процессов. Еще больше о нюансах работы аналитика – на бесплатном мастер-классе 7 мая, присоединяйтесь!

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

Сегодня я хочу поговорить о том, как, используя логику бизнес-процессов, научиться более четко работать с требованиями:

• быстро погрузиться в специфику автоматизируемого бизнеса, не зная предметной области;
• определить контур проекта, исходя из бизнес-требований;
• полно и корректно работать с требованиями нижних уровней, удерживая бизнес-требования, не давая проекту «расползтись», но при этом не упуская существенные детали.

Как перейти от бизнес-требований к требованиям к ИТ-системе

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

Шаг 1. Определяем цели автоматизации и выходим на бизнес-требования к «абстрактному» (еще не выбранному) ИТ-решению

Ключевые вопросы, на которые нам нужно ответить:

• Для чего нужна эта система?
• Как разработка или внедрение этой системы повлияет на эффективность компании?

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

Шаг 2. Уточняем боли

«Какие проблемы вы хотите решить за счет автоматизации?» Этот вопрос нам необходимо задать для того, чтобы еще раз перепроверить цели автоматизации и уточнить бизнес-требования. Поскольку, как мы выяснили ранее, заказчики не всегда корректно определяют цели автоматизации, вследствие чего с такими бизнес-требованиями потом невозможно работать.

Шаг 3. Определяем пути решения

Вопросы, которые нужно задать на этом шаге:

• Что именно нужно автоматизировать (области автоматизации, процессы, бизнес-функции)?
• Как эти процессы влияют на бизнес-цели, соотносятся с бизнес-требованиями к системе?

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

Как это делать, мы рассмотрим на примере ниже.

Шаг 4. Собираем и уточняем пожелания к функциям будущей системы

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

В данном случае мы работаем в зоне, которую Вигерс называет «Пользовательские требования». Мы должны сопоставлять пользовательские требования с бизнес-процессами, выделенными на Шаге 3, и не давать заказчикам смещать фокус на другие бизнес-области.

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

Шаг 5. Подбираем решения

Вопросы, с которыми мы работаем на этом шаге:

• Каким средством (инструментом) эти требования лучше всего решить?
• В каком программном продукте или за счет какого способа автоматизации это лучше сделать?

Вопросы только кажутся одинаковыми, но это не так.

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

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

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

Шаг 6. Выделяем способы реализации требований в конкретной системе

Основной вопрос, на который мы здесь отвечаем: «Какими средствами конкретной ИТ-системы лучше всего реализовать пользовательские требования?».

Шаг 7. Сопоставляем инструменты, которые мы выбрали на этапах 5 и 6, с бизнес-процессами, которые мы автоматизируем

Здесь мы должны задать себе и нашему заказчику следующие вопросы:

• Все ли действия бизнес-процессов, которые мы автоматизируем (автоматизация которых нам нужна для выполнения бизнес-требований) покрываются инструментами будущей ИТ-системы? Включая требования к НСИ, отчетности, интерфейсам, безопасности данных и прочие не функциональные требования.
• Поддерживают ли средства будущей ИТ-системы бизнес-логику? Не автоматизацию отдельных функций, а сквозную деятельность компании: связи между бизнес-процессами, логику трансформации данных в процессе работы предприятия и пр.

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

Чем здесь поможет процессный подход

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

1. Быстро погрузиться в специфику конкретного предприятия и область автоматизации, не имея бизнес-образования или образования в нужной предметной области (финансы, производство и пр.). Понять, с чем связаны те или иные требования пользователей.
2. Сопоставлять требования пользователей с бизнес-требованиями, определять практическую ценность тех или иных требований к системе для решения бизнес-задач автоматизации. Удерживать контур проекта в рамках бизнес-требований, не давать ему уйти в сторону или расползтись.
3. Обеспечивать полноту собираемых требований для решения бизнес-задач автоматизации. Учитывать не только функциональные, но и не функциональные требования. Комплексно подходить к достижению целей автоматизации.

Давайте разберемся с этими задачами на практических примерах.

Пример 1: Как определить контур проекта, не зная специфики бизнеса, и при этом не уйти в «бесконечную автоматизацию».

Вам необходимо автоматизировать производственное предприятие. Допустим, по производству удобрений и средств химической защиты растений. Цель автоматизации, которую озвучивает заказчик в лице генерального и финансового директора завода – сокращение себестоимости производства за счет более точного анализа и управления затратами. Вы ничего не понимаете в себестоимости и в производстве этой продукции. Что делать?

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

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

И, скорее всего, в случае с заводом выяснится, что основными факторами, влияющими на себестоимость этого конкретного вида производства, являются:

1. Себестоимость сырья, часть из которого привозят из-за рубежа, из–за чего присутствуют плавающие сроки поставки. Это означает, что в контуре нашего проекта оказываются процессы Управление закупками и запасами. Но не все процессы, а только те, которые относятся к цене и срокам поставки, объемам запасов. Здесь нужно балансировать между «большой объем, но за меньшие деньги и всегда в наличии на складе» и «сокращение затрат на хранение и замороженных средств в запасах». Далее при детализации этих процессов вам нужно фокусироваться на тех требованиях к системе, которые помогут решить эту задачу.
2. Брак и несоответствия, поскольку к такой продукции предъявляются очень высокие требования по составу входящих компонент, экологической безопасности и пр. Любое изменение в характеристиках сырья может привести к отклонениям в рецептуре, любая невнимательность на производстве – к браку. Это означает, что в контур нашего проекта попадают процессы:

• Входного контроля сырья – в части выявления отклонений в характеристиках сырья и оценки их потенциального влияния на свойства готовой продукции. Здесь нам важно будет автоматизировать учет результатов входного контроля и принятие решений о допуске сырья в производство.
• Управления производственной документацией (рецептурами и технологическими картами) – той, что задает четкие правила: какого сырья сколько добавить и как обрабатывать, чтобы получить нужную продукцию. И здесь нам важно автоматизировать учет изменений и информирование об изменениях документации – в т.ч. в связи с изменениями в сырье.
• Контроля качества в производстве. Начиная с выявления и учета отклонений в процессе производства (на линии) и заканчивая контролем готовой продукции. Опять же, при детализации этих процессов важно будет понять, в каких точках сейчас основные проблемы, приводящие к возникновению брака. И дальше работать с требованиями, позволяющими эти проблемы устранить.

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

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

Для реализации бизнес-требования «Сокращение себестоимости производства за счет более точного анализа и управления затратами» в периметр войдут два блока бизнес-процессов, по которым нужно собирать требования пользователей.

1. Основные бизнес-процессы, требования которых необходимо реализовать:

• Производственный учет и Расчет себестоимости – основные процессы, которые нужно будет автоматизировать. И в рамках производственного учета вы сразу рассмотрите варианты оптимизации ручных операций.
• Формирование отчетности по структуре себестоимости.

2. Смежные процессы, которые будут влиять на снижение себестоимости:

• Планирование и анализ запасов сырья;
• Планирование закупок (в части объемов, сроков и цен);
• Входной контроль сырья;
• Контроль качества готовой продукции и управление браком;
• Управление производственной документацией - только в части ее актуальности и изменений.

И тогда, если вдруг в процессе сбора требований к вам начнут поступать различные «хотелки» (из бухгалтерии по поводу рег. учета, из финансовой службы по поводу бюджетирования и планирования, из отдела закупок по поводу оперативной работы с поставщиками и т.д.), появятся закономерные вопросы: «К какому бизнес-процессу относятся эти требования?», «Включены ли эти процессы в контур проекта?», «Как эти требования влияют на управление себестоимостью?».

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

Пример 2: Как собрать полные и достаточные требования, не зная предметной области.

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

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

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

Для этого в процессном подходе используются так называемые атрибуты бизнес-процесса. Это ключевые элементы, из которых состоит бизнес-процесс, а также характеристики этих элементов. Если вы знаете, что такое бизнес-процесс, то вы должны знать, что у каждого бизнес-процесса есть:

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

Конечно, это не весь набор элементов бизнес-процесса, но сейчас нам важны именно они.

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

• сама продукция (в нашем случае это может быть баночка с удобрением);
• информация о том, что такая-то номенклатура, в таком-то объеме, такой-то партии имеет статус «брак».

Таким образом, при работе с требованиями смежных бизнес-процессов, мы должны:

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

Вокруг этого и нужно выстраивать вопросы при сборе данных о требованиях:

• С какого действия начинается ваш процесс (работы с браком, учета продукции и т.д.)?
• Какое действие вы совершаете следующим, и потом за ним и далее?
• Какую информацию вы используете на каждом шаге?
• Откуда вы ее получаете?
• Насколько этой информации достаточно? Что хотелось бы изменить?
• Какая информация получается в результате ваших действий?
• Куда вы передаете эту информацию, и так далее.

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

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

О том, как это научиться делать, мы с вами поговорим подробнее на бесплатном мастер-классе 7 мая в 13:00 (МСК).

Подробнее о мастер-классе

Еще больше информации о работе с требованиями – на курсе

18 мая начинается онлайн-курс «Процессный подход в проектах внедрения ERP-систем». Он фокусируется на работе с требованиями заказчика. Основная задача – научить выявлять, структурировать и формализовать требования с опорой на реальные бизнес-процессы компании.

Обучение длится 2 месяца, включает 40 академических часов и сочетает видеолекции, практику и вебинары с преподавателем. Формат гибкий: можно проходить материалы в своем темпе, при этом сохраняется доступ к поддержке и обсуждениям в Telegram-чате. После завершения выдается электронный сертификат Инфостарта при условии сдачи домашних заданий.

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