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

Что такое требования и какие они бывают?

Требования — это детально сформулированная и задокументированная задача, либо потребность от бизнес-подразделения. В РСХБ.Цифра мы используем термины "бизнес-требования" и "бизнес-функциональные требования". В бизнес-требованиях мы стараемся собрать цель и прообраз результата того, что мы планируем автоматизировать или создать, а также стараемся зафиксировать атрибуты и бизнес алгоритмы объекта автоматизации.

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

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

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

• количество проданных слитков за период в штуках,

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

• различные разрезы анализа (количество проданных слитков в штуках по филиалам, офисам продаж, ответственным подразделениям, за период или в динамике).

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

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

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

Как связать бизнес-требования с системой?

После формулирования верхнеуровневых требований необходимо определить системы, на которых будет осуществляться реализация. Это один из наиболее сложных этапов, поскольку в РСХБ, например, огромное количество различных ИТ-систем (Хранилище данных, Озеро данных, АБС, 1С и другие). Важно определить системы-источники на этапе формирования бизнес-требований и проверить, а есть ли данные в тех системах, которые мы определили как источники. Иначе на этапе разработке нас ждут боль и разочарование, пересмотр сроков и бюджетов.

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

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

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

Проводим расследование

Формирование бизнес-требований может представлять сложность для специалистов.

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

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

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

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

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

Методы взаимодействия с бизнес-заказчиком

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

Есть ли универсальный способ сбора требований? Да, он называется дотошность. Чем больше правильных вопросов мы зададим на встрече, тем корректнее будет текущее состояние процесса (AS IS) — как именно сейчас формируется конкретный отчет и бизнес процесс по сбору и использованию этого отчета конечным потребителями. Заказчик должен подробно рассказать, откуда он берет каждую цифру и как ее интерпретирует. Куда потом направляется данный отчёт, в каком формате, как часто, кому.

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

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

Разработка прототипа. Однако документирование текущего состояния не гарантирует успешной реализации. Для создания полноценного документа необходимо описать целевое состояние (TO BE) и разработать прототип. Прототип может представлять собой сокращенный формат будущего отчета или дашборда на тестовом срезе данных, чтобы бизнес-пользователи могли визуально оценить ожидаемый результат.

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

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

Как только удается достигнуть результата, который устраивает все заинтересованные стороны, прототип детально описывается в разделе to be.

Процесс внесения правок и согласования

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

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

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

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

Анализ кейсов

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

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

На что обращат�� внимание при формировании команды аналитиков

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

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

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

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

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

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

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

• из какой системы извлекаются данные,

• какие фильтры применяются,

• как производятся вычисления,

• как обновляются отчёты.

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

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

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

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