Сбор требований для проекта внедрения BI-системы (системы бизнес-анализа)
Сбор требований
Выявление требований – важный этап работ при внедрении BI системы. Моделирование для российских BI-платформ как и в любой системе бизнес анализа, начинается с чистого листа. Работа разработчиков заключается в создание визуальных представлений данных для приложений, проработке юзабилити интерфейсов и наполнением их удобными элементами управления. Техническая специализация в компании на высоком уровне. Следующая важная задача — это получить требования от заказчиков.
На практике часто встречается, когда бизнес пользователей просят заполнить документ или анкету для предоставления требований разработчикам. Зачастую заполнением анкеты занимается один человек или вовсе забывают заполнить. Прежде чем идти дальше, задайтесь вопросами: «А действительно ли это лучший способ? Можно ли по анкете получить полноценное представление по необходимым требованиям к системе?»
Стоит отметить, что BI системы обладают достаточной гибкостью для разработки по спиральной модели. Данная модель разработки сочетает в себе процесс проектирования и постадийного прототипирования. Следовательно, в BI возможно вести разработку при отсутствии полного понимания требования на начальных этапах. Несмотря на данное преимущество не рекомендуется полностью игнорировать этап сбора требований.
Любая успешная информационная система состоит из трех элементов:
- полезность;
- удобство использования;
- использование.
Использование – это следствие полезности функциональности системы и удобства ее использования. Итак, как этого добиться?
Во-первых, нужно определить целевую аудиторию системы. Создавать дашборд в надежде, что «пользователи придут на продукт» – плохой путь к успеху. Привлекайте аудиторию на ранних этапах проекта. Это позволит развивать проект в соответствии с потребностями пользователей и сосредоточить усилия на действительно важных аспектах.
Адаптируйте дизайн дашбордов к потребностям конкретных людей. Поэтому важно в начале определить конечных пользователей и выстроить с ними коммуникации. Давайте рассмотрим на живом примере. Задача – создать единую информационную панель для линейных менеджеров, которые следят за сотрудниками контакт-центра. Под проект была собрана команда и проведена демонстрация заказчику. На периодических совещаниях обсуждались проблемы менеджеров. Важно было определиться с тем, что проблемы возможно решить. И только потом были заданы вопросы, а что бы они хотели видеть. На первых встречах намеренно не вводите ограничения, чтобы бизнес пользователи удерживали фокус внимания. Слово «нет» или другие ограничения могут отталкивать людей.
Важно вначале проекта просить клиента оценивать и расставлять приоритеты в своих «потребностях и желаниях» по критериям: Высокий/Средний/Низкий или, можно использовать схему классификации приоритетов MoSCoW. (http://businessanalystlearnings.com/ba-techniques/2013/3/5/moscow-technique-requirements-prioritization)
Обратите внимание на действующий информационный менеджмент в компании. Цель заключается в том, чтобы понять, задокументировать ключевые показатели эффективности (KPI) и их методологию расчета. Проверяйте все доступные источники, чтобы убедиться в единстве данных. Никогда не предполагайте, что результаты в отчетах идентичны, даже если они должны быть такими. Срок действия отчетов мог истечь. Сам отчет может быть не актуальным, при этом будет отображаться в системе и продолжать вычисления. Выявленные факты несоответствия необходимо выделить и получить от клиента четкий ответ по отчету.
После того, как логика расчетов ясна, необходимо вернуться к источнику данных и бегло просмотреть. Быстрый анализ часто дает ответы о том, как нужно обрабатывать информацию. Обратите внимание, если таблицы с данными большие, то не все поля возможно потребуются. Обычно для расчетов и фильтров требуется часть данных, другая часть используются только в детализированном листе информационной системы. Задавайте уточняющие вопросы:
- Какие поля необходимо загружать?
- Все ли данные заполнены?
- Какие идентификаторы нужны для справочных таблиц?
- Как они используются?
- Задокументировано ли их использование в словаре данных (Data Dictionary)?
Для проверки целостности данных разработан инструмент/утилита (подходит при работе с CSV-файлами) http://community.qlik.com/docs/DOC-3352
Теперь требованиям необходимо придать форму. Сейчас все идеи, наработки, KPI собраны в простой список. Проанализируйте, насколько возможно реализовать каждое требование при разумных затратах и с приемлемой производительностью. Выделите требования, которые невозможно реализовать, указав причину. Определите приоритеты требований и скомпонуйте всю информацию в единый документ. Пример распределения указан на рисунке.
В определении приоритетов должны участвовать разные заинтересованные лица, представляющие клиентов, руководство проекта и другие. Расставлять приоритеты лучше во время встречи, а не отправлять предложение по электронной почте. Разработку можно разделить на этапы, чтобы быстрее реализовать первые дашборды, пропуская некоторые низкоприоритетные функции, которые появятся позже.
Благодаря качественному процессу проработки данных по основным моментам, требования будут корректны, отражать желаемые качественные характеристики и удовлетворять потребности клиента.
Данные
- Какая глубина хранения данных является достаточной?
- Какая частота обновления данных необходима?
- Можно ли агрегировать архивные данные?
Ключевые поля
- Какие индикаторы необходимо включить в качестве ключевых фильтров на дашборд?
- Какие показателя являются ключевыми (KPI)?
- Какие поля необходимы детализировать (для подробного просмотра данных)?
Особенности
Возьмите за основу результаты интервью и запишите в простой форме основные требования к визуализации (не нужно вдаваться в технические особенности), например,
- просмотр трендов по KPI в разрезе день, неделя, месяц;
- ТОП-5 лучших исполнителей в группировке по командам и отдельным лицам;
- возможность анализировать результаты по каждому KPI в табличной форме по объектам, командам и отдельным лицам.
И наконец….
- утверждение требований. Убедитесь, что заинтересованные лица согласны и понимают, что именно и в каком порядке будет разрабатываться. План проекта поможет понять сроки разработки;
- держите пользователей в курсе и не позволяйте коммуникациям прекращаться;
- предоставляйте бизнес-пользователям периодически обновления и демоверсии;
- привлекайте пользователей для проверки расчетов, тестирования функциональности и подтверждения корректности данных в процессе разработки.
Контрольный список сбора требований
Выявив и проанализировав требования, важно подтвердить качество и верность решения, которое описано в требованиях. Изучение контрольного списка требований позволяет удостовериться в том, что все основные требования к системе учтены. В разделе собран контрольный список критериев и типов вопросов для выявления требований.
-
Реестр показателей/измерений, включает:
- детали расчета (наименование полей, источники данных, формулы расчетов);
- приоритетность (например, какие показатели определяют KPI, а какие нужно отобразить в сводке);
- измерения для определения трендов (например, время, магазин, продукт).
-
Фильтры:
- каковы критерии сортировки в каждом поле (в т.ч. расположение);
- как группировать данные (например, продукт, отдел и т. д.);
- доступность параметров (например, на панели слева установлено восемь приоритетных фильтров).
-
Список таблиц (это совокупность показателей и параметров, указанных выше):
- месторасположение;
- частота обновления;
- тип нагрузки (инкрементальная/загрузка и замена);
- дополнительные требования (например, альтернативные измерения);
- какие поля необходимы для детализации информации;
- требования к историчности, включая агрегирование.
-
Список ключевых диаграмм/ визуализаций:
- тип диаграммы (например, линейная, столбчатая, комбинированная, плоская и сводная таблица);
- уровень детализации (например, иерархическая структура);
- неиерархические группы (например, гистограммы, циклические группы включают несколько полей по показателям A, B, C).
-
Функциональность панели мониторинга (dashboard):
- каков типичный и максимальный размер отчета;
- частота/периодичность обновления;
- прочие требования к функциональности.
-
Пользователи:
- кому необходимо предоставить доступ;
- когда прогнозируется пик нагрузки (для предварительного расчета загрузки системы);
- требования к информационной безопасности (ограничения прав, доступа к данным);
- как будет осуществляться доступ к системе (облако, браузер, планшет);
- опции для дальтоников;
- языковые требования.
- Общие/другие требования (например, SLA поддержки BAU).
