Методика разработки бизнес-требований в проекте по автоматизации. Часть 1

Первая часть в серии статей про разработку бизнес-требований в проекте по автоматизации. В данной статье рассматривается трассировка: требование к бизнесу - требование к решению - требование к системе

Часть 1 | Часть 2 | Часть 3 | Часть 4

Введение

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

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

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

Трассировка требований

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

1. Требования к бизнесу

2. Требования к решению

3. Требования к системе

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

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

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

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

• BABOK Guide

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

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

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

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

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

4. требуется определённым образом

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

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

Требование к бизнесу

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

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

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. и др.

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

Добавим в нашу канву разработки требования ещё важный параметр — основание для выполнения требования:

• нормативно-правовой акт, в котором это требование содержится

• условие, при которых это требование вступает в силу.

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

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

• собрать данные о доходах и расходах,

• сформировать на основании этих данных декларацию по налогу на прибыль,

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

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

• Устав

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

• Положения

• Правила

• Приказы

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

• Регламент

• Порядок

• Методика

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

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

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

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

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

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

• и другое.

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

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

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

   1. через личный кабинет налогоплательщика,

   2. через специализированную бухгалтерскую программу.

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

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

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

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

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

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

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

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

3. Рабочая инструкция по проверке декларации по налогу на прибыль

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

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

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

Требование к системе

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

Система должна для пользователя с ролью «главный бухгалтер» предоставить декларацию по налогу на прибыль не более чем через 8 часов после начала запроса, в формате XML, по форме по КНД 1151006.

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

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

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

Заключение

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

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

   1. требования к бизнесу

   2. требования к решению

   3. требования к системе

2. Требования к бизнесу можно разделить на три уровня:

   1. к организации,

   2. к владельцам бизнес-процессов,

   3. к владельцам бизнес-функций

3. Требования к бизнесу официально закрепляются в нормативных актах.

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

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

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

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

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

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

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