ЛЮСТРА: Методика разработки бизнес-требований в проекте по автоматизации бизнес-процессов

А вы сталкиваетесь с постоянными изменениями требований со стороны заказчиков?

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

Авторская методика ЛЮСТРА помогает аналитику разработать бизнес-требования таким образом, чтобы минимизировать последующие изменения требований со стороны заказчиков в проекте по автоматизации бизнес-процессов. Ее цель — направить разговор со стейкхолдерами в сторону целей бизнеса, чтобы выявить легитимные и обоснованные потребности. Преимущество методики заключается в использовании мнемотехник, что делает ее легко запоминаемой и применимой в любом интервью с заказчиком.

Введение

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

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

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

Сфера применения методики ЛЮСТРА

Какие проблемы решает

Методика ЛЮСТРА решает следующие проблемы:

1. Частое изменение требований на проекте со стороны бизнеса из-за того что: 

   1. Были собраны требования не с лиц, принимающих решения. 

   2. Были собраны требования не всех заинтересованных лиц. 

   3. В настроенных процессах что-то делается по инерции и заказчики приходят к осознанию этого слишком поздно: в середине, в конце проекта, во время опытно-промышленной эксплуатации.

   4. Во время опроса стейкхолдеры сформулировали решения, а не потребности.

   5. При сборе требований были учтены не все этапы работ, которые затронуты проектом. 

2. Заказчики изначально формулируют конкретные решения и аналитику сложно в разговоре с ними перейти на выявление потребностей.

3. Заказчики формулируют нефункциональные требования к системе, взятые «из воздуха», особенно в виде «магических чисел» вроде «отчет должен формироваться за пять минут».

В каких проектах

Наилучшим образом методика ЛЮСТРА проявляет себя в проектах, для которых верно одно или несколько из следующих утверждений:

1. Это проект по развитию существующей информационной системы.

2. Это стартовая автоматизация в компании со сложными бизнес-процессами.

3. В корпоративной среде произошел сдвиг в сторону требований к системе, когда и сами заказчики, и бизнес-аналитики формулируют требования к системе, а не бизнес-требования.

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

Как соотносится с другими методиками

Методика детализирует и уточняет существующие стандарты по разработке требований: ISO/IEC/IEEE 29148, BABOK Guide, онтологию Вигерса, INCOSE.

В методике не рассматриваются другие этапы работы с требованиями в проекте по автоматизации:

• определение проблем, целей и ограничений проекта, 

• определение списка стейкхолдеров,

• процесс интервьюирования,

• описание бизнес-процессов,

• генерация вариантов решений,

• проработка системных требований.

Описание методики ЛЮСТРА

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

Представленная схема похожа на люстру — по этой мнемотехнике можно запомнить методику разработки бизнес-требований.

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

• Юзер

• Стори: формулируем потребности стейкхолдеров, которые возникают из предъявленных к ним требований, контекста, в котором эти требования приходится выполнять, и личных интересов. Формулируем, например, в формате User Story

• Требование к

• Решению: потребности стейкхолдеров определяют требования к решению.

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

При опросе стейкхолдера проекта, который является ответственным сотрудником предприятия, следует действовать в следующей последовательности:

1. Найти ИКС — место возникновения изменения, которое привело к формированию потребности. Выясняем, нужного ли стейкхолдера мы опрашиваем.

2. Сформулировать БИЗНЕС-требование: выяснить требование к бизнесу в лице ответственного сотрудника. Проверяем источники и предпосылки требований.

3. Провести ОПРОС: определить, что формулирует стейкхолдер. Подталкиваем его к тому, чтобы вместо конкретных требований сформулировать потребности.

4. Сформулировать потребности ответственного сотрудника в формате User Story или Job Story: что ему нужно для того, чтобы выполнить взятые на себя обязательства.

5. Выявить СВОД бизнес-функций, которые затрагивает потребность в данном бизнес-процессе. Выявляем неявные и подразумеваемые требования, расширяем список стейкхолдеров для опроса.

6. Сформулировать требования к решению на основании потребностей и выявленного реестра бизнес-функций.

Рассмотрим подробно каждый шаг методики.

1. Найти ИКС

ИКС — место возникновения изменения, которое привело к формированию потребности.

Выясняем, нужного ли стейкхолдера мы опрашиваем:

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

• Если причина изменений заключается в изменении требований к сотруднику, тогда сначала надо убедиться в легитимности требований. Заканчиваем интервью с этим сотрудником и назначаем интервью с сотрудником, с которого началось изменение требований.

• Если причина изменений кроется в контексте, надо смотреть по ситуации.

1.1. Пояснения: интересы, контекст, требование к сотруднику

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

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

• требования, которые человек должен выполнять

• в определённом контексте,

• не ущемляя своих интересов.

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

1.2. Сквозной пример с налоговой декларацией

Исходное требование от главного бухгалтера:

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

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

2. Сформулировать БИЗНЕС-требование

Прежде чем выявить потребности сотрудника, выясняем: а что требуется от него самого? Задайте вопросы заказчику по мнемотехнике БИЗНЕС и сформулируйте требования по канве:

• База требования. В каком нормативном акте содержится требование к бизнесу в лице ответственного сотрудника? Если требование нигде не прописано, то кто источник требования? При каком условии это требование вступает в силу?

• Исполнитель. Кто должен выполнить требование?

• Заказчик. Кто выгодоприобретатель? Кто будет принимать исполнение требования?

• Нормативная Единица требования. В чём заключается требование? Что именно нужно выполнить? Какое действие с каким объектом нужно совершить?

• Стандарт требования. По каким параметрам требование можно считать выполненным? Место, время, продолжительность, формат, образ действия.

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

2.1. Пояснения: требование к бизнесу

В рамках методики ЛЮСТРА бизнес-требования трактуются как требования к бизнесу, то есть то, что требуется от организации: выполнить обязательства, которые взяли на себя лица, ответственные за процессы на каждом иерархическом уровне компании и которые зафиксированы в нормативно-правовых актах страны, договорах с третьими лицами или во внутренних документах организации.

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

1. Нормативно-правовые акты:

   1. Конституция РФ

   2. Международные договоры

   3. Федеральные законы

   4. Указы президента

   5. Постановления правительства

   6. Постановления главного санитарного врача РФ

   7. Региональное законодательство

   8. Муниципальные акты

   9. Приказы федеральных министерств

   10. Указания и положения Банка России

   11. Приказы служб

2. Требования от основателей, владельцев, акционеров:

   1. Бизнес-модель

   2. Концепция

   3. Миссия

   4. Бизнес-план

   5. Стратегия развития компании

3. Обязательства перед третьими лицами — клиентами, контрагентами, сотрудниками:

   1. Договор оферты

   2. Договор купли-продажи

   3. Договор аренды

   4. Договор об оказании услуг

   5. Трудовой договор

   6. Гражданско-правовой договор

   7. и др.

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

• Устав

• Учетная политика

• Положения

• Правила

• Приказы

• Должностная инструкция

• Регламент

• Порядок

• Методика

• Рабочая инструкция

2.2. Сквозной пример с налоговой декларацией

Согласно методике ЛЮСТРА не надо заходить слишком далеко для определения требования к бизнесу: достаточно найти зафиксированное требование к опрашиваемому ответственному лицу.

Однако для примера начнем с формулировки требования к организации:

На основании главы 25 НК РФ при наличии соответствующей организационно-правовой формы и объекта налогообложения российское юридическое лицо должно в инспекцию ИФНС предоставить декларацию по налогу на прибыль не позднее 25 числа месяца, следующего за отчетным кварталом, в электронной или бумажной форме, установленной приказом ФНС России.

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

На основании должностной инструкции, подписанной генеральным директором, главный бухгалтер должен в инспекцию ИФНС предоставить декларацию по налогу на прибыль не позднее 25 числа месяца, следующего за отчетным кварталом, в электронной или бумажной форме, установленной приказом ФНС России от 23.09.2019 N ММВ-7-3/475.

3. Провести ОПРОС 

Определить, что формулирует стейкхолдер:

Уводим стейкхолдера от формулирования конкретных требований к системе, решению или другому ответственному сотруднику, направляем разговор в сторону бизнеса.

3.1. Пояснения: требование к решению, ответственному лицу, системе

Понятие требований в следующих документах:

• Стандарт IEEE 610.12−1990

• Стандарт ISO/IEC/IEEE 29148

• Российский ГОСТ 34.601−90

• BABOK Guide

• Руководство по написанию требований международного совета по системной инженерии (INCOSE)

• организационно-управленческий подход Six Sigma

трактуется со следующих точек зрения:

1. требуется от чего-то или кого-то

2. требуется кому-то

3. требуется что-то

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

• к решению проблемы

• к системе,

• к другому лицу

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

3.2. Пояснения: опасения и ожидания ответственного лица

Стандарт ISO/IEC/IEEE 29148 и Руководство по написанию требований международного совета по системной инженерии (INCOSE) выделяют требования стейкхолдера отдельно от бизнес-требований. В стандарте ISO/IEC/IEEE 29148 потребности описываются понятием concerns — опасения, в INCOSE используется слово expectations — ожидания. В методике ЛЮСТРА предлагается:

• выделить выявление опасений и ожиданий и выявление потребностей в два разных этапа

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

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

• какие риски стейкхолдер несёт при невыполнении взятых на себя обязательств?

• что стейкхолдеру нужно, чтобы выполнить взятые на себя обязательства?

3.3. Сквозной пример с налоговой декларацией

Напомню исходное требование от главного бухгалтера:

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

Хотя требование сформулировано в виде User Story, по сути это требование к системе. Для того чтобы вернуть главного бухгалтера на формулирование потребности, можно зайти издалека и опросить в произвольном формате об опасениях и ожиданиях.

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

«Я боюсь сдать некорректную налоговую декларацию из-за того, что я не успею её проверить, а данных очень много. Потом придётся отвечать на запросы от налоговой инспекции по камеральной проверке»

«Я боюсь не сдать налоговую декларацию вовремя из-за того, что программа долго её рассчитывает и отправляет, тогда придётся платить штраф».

Когда риски проработаны и найдены точки бизнес-процесса, влияющие на подбор решения, мы узнаём от ответственного лица его ожидания, которые в нашем примере могут звучать так:

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

«Я закладываю один день на то, чтобы сверить данные налоговой декларации с данными налогового учета».

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

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

4. Сформулировать потребности

Ворох опасений и ожиданий мы приводим в более формализованный вид потребностей. Их можно описывать в разных форматах, рассмотрим два из них: User Story и Job story. В рамках методики ЛЮСТРА эти два формата подчеркивают место возникновения потребности:

• Интересы

• Контекст

• Требование к сотруднику

User Story — способ описания потребности, сформулированный как одно или более предложений на повседневном или деловом языке пользователя. В рамках методики ЛЮСТРА User Story следует применять, если место возникновения потребности — интересы стейкхолдера или требование к нему.

Изначально Job Story — фреймворк из концепции Jobs To Be Done для исследования целевой аудитории, её мотивов и проблем. В целях данной методики этот способ используется, если нужно сосредоточить внимание на контексте, в котором у ответственного лица возникли сложности.

Составляющие части форматов:

• Роль, которую выполняет ответственное лицо в компании.

• Интересы, выполнение которых закроет основные опасения и ожидания ответственного в проекте по автоматизации.

• Контекст, в котором у ответственного лица возникла потребность.

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

4.1. Сквозной пример с налоговой декларацией

В нашем примере мы определили основную потребность главного бухгалтера:

5. Составить СВОД бизнес-функций

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

• Событие: итог бизнес-процесса

• Выбор: решения, которые нужно принимать в рамках данного бизнес-процесса

• Операция: действия, которые нужно выполнять в рамках данного бизнес-процесса

• Данные: информация, которую нужно собрать, обработать, сохранить и предъявить в рамках данного бизнес-процесса

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

5.1. Пояснения: разветвление требований к бизнесу

Метасистема требований по методике ЛЮСТРА отличается от указанной в BABOK двумя предпосылками:

• бизнес-требования трактуются как требования к бизнесу

• предлагается вместо сбора требований заинтересованных сторон выявлять потребности ответственных лиц

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

5.1. Пояснения: бизнес-процессы

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

Пример бизнес-процессов розничного магазина:

Управляющие бизнес-процессы:

1. Управление персоналом

   • Найм и адаптация новых сотрудников.

   • Оценка и мотивация персонала.

2. Финансовое управление

   • Ведение учета и отчетности.

   • Контроль кассовых операций и банковских переводов.

Операционные бизнес-процессы:

1. Управление товарными запасами

   • Закупка товаров.

   • Управление запасами и складом.

   • Инвентаризация.

2. Продажи

   • Обслуживание клиентов на кассе.

   • Консультации и помощь покупателям в торговом зале.

   • Оформление специальных заказов.

3. Маркетинг и продвижение

   • Разработка и реализация маркетинговых кампаний.

   • Управление акциями и скидками.

Обеспечивающие бизнес-процессы:

1. Информационные технологии

   • Обеспечение безопасности данных.

   • Поддержка и обновление программного обеспечения.

2. Управление качеством

   • Контроль качества товаров и услуг.

   • Обработка жалоб и предложений клиентов.

3. Логистика и доставка

   • Организация доставки товаров до магазина.

   • Хранение товаров на складе.

5.2. Пояснения: бизнес-функции

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

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

Любой бизнес-процесс можно разложить на следующие бизнес-функции, которые описываются словом СВОД:

• Событие: итог бизнес-процесса

• Выбор: решения, которые нужно принимать в рамках данного бизнес-процесса

• Операция: действия, которые нужно выполнять в рамках данного бизнес-процесса

• Данные: информация, которую нужно собрать, обработать, сохранить и предъявить в рамках данного бизнес-процесса

Рассмотрим подпроцесс: «Обслуживание покупателя на кассе». В соответствии с моделью СВОД, бизнес-функции можно описать следующим образом:

1. Событие: покупателю выдан товар и чек о покупке

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

3. Операции:

   • Сканирование товаров и вывод итоговой суммы к оплате.

   • Принятие оплаты от покупателя (наличными или через POS-терминал).

   • Выдача сдачи, если требуется

   • Печать чека.

4. Данные:

   • Данные о ценах на товары, которые покупатель хочет приобрести.

   • Данные о специальных предложениях (скидках и акциях).

   • Данные о способах оплаты, доступных в магазине.

   • Данные о наличии или отсутствии необходимости в выдаче сдачи.

   • Записи о продажах для последующей отчетности и аналитики.

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

5.3. Пояснения: трассировка и накопление требований

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

Например, требование к бизнесу:

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

Это требование может быть, в итоге, реализовано совершенно разными способами, возьмем два варианта решения:

• чек выдает кассир,

• покупатель выбивает себе чек на кассе самообслуживания

Первое решение определяет требование к владельцу бизнес-функции:

Должностная инструкция кассира: после подтверждения факта оплаты товаров кассир должен покупателю выдать кассовый чек, распечатанный на ККТ сразу после осуществления расчета.

Требование к другому решению, включающее в себя кассу самообслуживания, звучит так:

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

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

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

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

5.4. Сквозной пример с налоговой декларацией

Выделим в процессе сдачи налоговой декларации следующие функции:

События:

• Сдача налоговой декларации по налогу на прибыль в налоговый орган.

• Получение подтверждения о принятии декларации.

Выбор:

• Определить, можно ли запускать расчет налоговой декларации

• Определить, корректна ли налоговая декларация, то есть готова ли для подачи в ИФНС

• Определить, допустим ли рассчитанный налог на прибыль

• Определить, нужно ли вносить корректировки в учет и в декларацию

Операция:

Формирование налоговой декларации — внесение данных в налоговую декларацию, включая доходы, расходы, налоговые вычеты и льготы.

Данные:

• Финансовая информация: суммы доходов и расходов за отчетный по данным налогового учета.

• Информация о применяемых налоговых льготах и вычетах.

• Полные реквизиты предприятия

• Документы, подтверждающие финансовые операции

Перед тем как перейти к формулированию требования к решению, необходимо проанализировать информацию по каждой из бизнес-функций:

• Кто или что сейчас выполняет эту функцию?

• Можем ли мы доверять выполнению операций и предоставляемым данным сейчас?

• Кто сейчас делает выбор?

• Как распознаются события сейчас?

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

6. Сформулировать требование к решению

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

• создании продукта,

• автоматизации процесса,

• обучении сотрудников,

• оптимизации бизнес-процессов,

• найме новых сотрудников

• аутсорсе, и т.д.

Требование к решению можно описать по канве разработки любого требования:

6.1. Сквозной пример с налоговой декларацией

Предположим, что главный бухгалтер как владелец процесса по сдаче налоговой декларации отразил в нормативных актах организации следующие решения:

1. Учетная политика предприятия в целях налогообложения

   1. Декларация по налогу на прибыль должна быть предоставлена в электронной форме, установленной приказом ФНС России, через личный кабинет налогоплательщика.

   2. Декларация по налогу на прибыль должна отражать сумму налога на прибыль на основании корректно подсчитанных доходов и расходов, расчет которых соответствует главе 25 НК РФ.

2. Регламент учёта доходов и расходов

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

Также мы выяснили потребность главного бухгалтера:

Как главный бухгалтер, я хочу иметь в запасе как минимум 4 дня, чтобы успеть проверить налоговую декларацию до 25 числа месяца, следующего за отчетным кварталом.

Требование к решению опишем по канве:

Решение должно для главного бухгалтера предоставить декларацию по налогу на прибыль не ранее 19 числа месяца, чтобы были подсчитаны все доходы и расходы, и не позднее 20 числа месяца, следующего за окончанием отчётного квартала, чтобы осталось время на проверку налоговой декларации, в электронной форме, установленной приказом ФНС России.

7. А потом всё остальное…

Требование к решению в зависимости от проблем и целей проекта, рисков и выгод поможет подобрать правильные решения для бизнеса, некоторые из них потом трансформируются в требование к системе. Эти этапы уже не входят в методику ЛЮСТРА, однако на сквозном примере можно проследить, как методика помогает в дальнейшем описать требования к системе.

При перечислении бизнес-функций по методу СВОД мы выяснили, что необходимо:

• предоставить налоговую декларацию в ИФНС,

• для этого налоговую декларацию нужно сформировать,

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

По таймеру на 10:00 20-го числа месяца, следующего за отчетным кварталом, система должна для пользователя с ролью «Главный бухгалтер» рассчитать и вывести на экран декларацию по налогу на прибыль не более чем через 8 часов после начала запроса по форме по КНД 1151006 с возможность скачать декларацию в формате XML.

Как мы проследили, требование к системе не возникло «из воздуха»:

1. Требование к решению о том, что декларация должна быть сформирована не ранее 19 и не позднее 20 числа месяца, следующего за отчетным кварталом, преобразовалось в требование к системе, что время формирования декларации должно быть не более одного рабочего дня, то есть восьми часов. Это не соответствует исходному требованию главного бухгалтера, что декларация должна быть сформирована за полчаса. Оказывается, она может быть сформирована и за полчаса, и за час, и за четыре — главное, не больше восьми.

2. Требование к решению о том, что декларация должна быть сдана в электронной форме, установленной приказом ФНС России, выразилось в конкретных системных требованиях: форме и формате.

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

В соответствии с должностной инструкцией бухгалтера по налоговой отчетности и регламентом учета доходов и расходов при наличии наиболее полной информации о доходах и расходах бухгалтер по налоговой отчетности должен главному бухгалтеру предоставить декларацию по налогу на прибыль, отражающую сумму налога на прибыль, расчет которой соответствует главе 25 НК РФ, не ранее 19 числа месяца, не позднее 20 числа месяца, следующего за окончанием отчётного квартала, в формате PDF.

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

На основании потребности и СВОДа бизнес-функций сформулируем требования к решению:

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

При наличии подсчитанных доходов и расходов решение должно бухгалтера по налоговой отчетности обеспечить формирование декларации по налогу на прибыль, отражающую сумму налога на прибыль, расчет которой соответствует главе 25 НК РФ не ранее 19 числа месяца, не позднее 20 числа месяца, следующего за окончанием отчётного квартала, в формате XML для отправки в ИФНС и в формате PDF для предоставления главному бухгалтеру на проверку.

На основании этих требований к решению будут сформулированы свои требования к системе.

Еще пример использования методики

Производственная компания, проект по автоматизации нового бизнес-направления.

Поступило исходное требование от оператора склада:

В системе в документе «Накладная» рядом с кнопкой печати накладной мне нужна отдельная кнопка для печати транспортной накладной.

1. Найти ИКС: выясняем место и причину изменений.

Почему раньше кнопка была не нужна, а теперь понадобилась?

Выясняем причину изменений: изменилось требование к сотруднику.

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

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

2. Сформулировать БИЗНЕС-требование

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

3. Провести ОПРОС

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

4. Сформулировать потребность

Направляем ход разговора в сторону формулирования потребности руководителя отдела продаж:

5. Сформулировать СВОД бизнес-функций

Процесс «Продажи», подпроцесс «Выставление документов, подтверждающих факт продажи». Разложим его на бизнес-функции:

События, которые являются итогом бизнес-процесса:

• Доставка товара: клиент получает товар вместе с накладной и товарной накладной.

• Самовывоз: клиент забирает товар с накладной.

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

• Определить способ получения товара (доставка или самовывоз) и принять решение о необходимости печати определенных документов в зависимости от выбранного способа получения товара.

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

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

• Принять заказ и выбор способа получения товара

• Сформировать необходимые документы в зависимости от выбранного способа получения

• Проверить корректность подготовленных документов

• Распечатать документы

• Выдать документы клиенту вместе с товаром

• Сохранить копии документов для внутреннего учета и отчетности

Данные, которые нужно собрать, обработать, сохранить и предъявить в рамках данного бизнес-процесса

• Информация о заказе (номер заказа, дата, наименование товара, количество)

• Информация о клиенте (ФИО, адрес доставки, контактные данные)

• Информация о способе получения товара (доставка или самовывоз)

• Информация для оформления транспортной накладной в соответствии с требованиями законодательства

6. Сформулировать требования к решению

На основании выявленных потребностей руководителя отдела продаж мы можем составить следующие требования к решению:

ТВ соответствии с требованием к решению впоследствии вместе с заказчиком можно разработать разные варианты решения, например:

1. Внедрение электронного документооборота, который исключит нужду в печати.

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

3. Автоматизация существующей системы:

   1. в случае наличия в накладной услуги доставки, программное обеспечение автоматически должно формировать и «Накладную», и «Транспортную накладную».

   2. в случае включения накладной в план по доставке, программное обеспечение автоматически должно формировать и «Накладную», и «Транспортную накладную».

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

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

Метасистема требований в проекте по автоматизации

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

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

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

• требования законодательства,

• глобальный контекст — рыночные спрос и предложение, тренды, экологическая повестка, развитие технологий, особенности географии и погоды,

• потребности бизнеса, 

• потребности и опасения стейкхолдеров,

• бенчмаркинг: как это реализовано у конкурентов, или в этой же компании в другом подразделении 

2. При переходе от бизнес-требований к требованиям к решению необходимо оставить следующую информацию:

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

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

• набрасываем список вариантов решений,

• отделяем те варианты решений, которые точно будут переформулированы в виде требований к ответственным, а не требования к системе

3. Для работы над требованиями к системе должна остаться следующая информация:

• список требований стейкхолдеров к решению, каждое из которых представляет собой:

  • функциональное требование, которое может быть выполнено с помощью системы,

  • набор нефункциональных требований в виде бизнес-правил,

  • набор нефункциональных требований, ограниченных локальным контекстом

• список стейкхолдеров, включая непосредственных пользователей системы, например, администраторов и операторов

Заключение

В проекте по автоматизации ключевыми являются требования к системе, однако они не должны возникать «из воздуха». С помощью методики ЛЮСТРА мы подсвечиваем заказчику направление, по которому мы должны пойти, чтобы разработать корректные бизнес-требования. Необязательно быть профессионалом и разбираться в предметной области, просто нужно начинать с того, чтобы уточнить у стейкхолдеров, на основании чего они действуют и принимают решения, что они должны и кому, и почему именно сейчас возникла потребность в изменениях.

Методика направлена на развитие способности видеть за программным кодом живой организм компании, его потребности и потребности его клиентов, выступая своеобразным напоминанием о первичности бизнеса перед системой. Она применяется при опросе стейкхолдера, когда сам заказчик формулирует требования на языке взаимодействия пользователя с системой: «Я хочу, чтобы система сама формировала», «Алгоритм должен рассчитать», «Мне нужна кнопка» — и помогает направить разговор о разработке требований в сторону бизнеса.

Методика минимизирует последующие изменения требований в течение проекта за счет того, что в начале проекта:

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

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

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

4. Выявляем неявные и подразумеваемые требования, а также пропущенных стейкхолдеров.

5. Готовим почву для функциональных и нефункциональных требований к системе.