Disclaimer
Все мы видим, что сфера продвинутой аналитики набирает обороты и все больше специалистов интересуются данной областью. При этом понятной и доступной информации о построении процесса бизнес-анализа при разработке аналитических приложений в открытых источниках не так много. Поэтому очень сложно определиться с правильным рецептом (последовательностью действий) в рамках данного направления. В связи с этим я решил систематизировать ключевые ингредиенты и поделиться с вами пошаговой инструкцией, которая описывает действия аналитика по проработке предметной области и превращении туманной задачи «сделай то, не знаю что» в детальные требования к будущему приложению.
Приведенное ниже описание процесса будет строиться исходя из специфики разработки аналитических приложений в нашей компании. Материал будет полезен не только разработчикам приложений, но и начинающим BI-аналитикам.
Итак, начнем!
Процесс анализа в наших проектах по разработке аналитических приложений состоит из следующих этапов:
- Постановка задачи и начало работы;
- Обследование заказчика и работа с открытыми источниками;
- Анализ, формирование требований и документирование;
- Формирование итогового документа «Описание приложения».
Постановка задачи и начало работ
Работы начинаются с того, что приходит менеджер по продажам со словами: «Есть некая компания «Рога и копыта», ей очень нужно какое-нибудь аналитическое приложение». Такая формулировка задачи встречается в нашей жизни довольно часто, и мы к этому давно привыкли.
Поэтому первым вопросом, которым мы задаемся, чтобы в итоге получилось не «какое-нибудь», а полезное заказчику приложение, является вопрос: «Какая у этого заказчика есть «боль» (проблема), которую он мог бы решить с помощью анализа данных?»
Ответ на этот вопрос можно получить двумя путями:
- Спросить у заказчика. Путь правильный, но боль заказчика желательно знать еще до первой встречи, чтобы «понравиться» ему с порога и говорить с ним на одном языке. Хотя зачастую заказчик сам не знает свои узкие места в конкретных процессах или же просто не может их сформулировать.
- Самостоятельно найти ответ в открытых источниках + привлечь экспертов в предметной области. В случае с заказчиком, который не понимает, какую проблему он хочет решить, данный курс является единственно возможным. Думаю, эта ситуация объясняется тем, что, находясь «внутри» своего бизнеса, заказчику сложно взглянуть на него со стороны и четко выделить свои проблемные зоны.
Поэтому в нашей практике мы часто идем по второму пути, когда работа аналитика до первой встречи с заказчиком посвящена самостоятельному глубокому изучению открытых источников (проще говоря, мы активно гуглим и яндексим). Мы ищем информацию, которая дает ответы на следующие вопросы:
- Какие процессы выполняются в бизнесе заказчика или в аналогичном бизнесе у других компаний на рынке?
- Какие данные циркулируют внутри такого бизнеса?
- Какие проблемы встречаются в таком бизнесе у нашего заказчика или же у других компаний?
- Какие тактические и стратегические цели ставят себе такие компании?
- Какие ключевые показатели оценки эффективности (KPI – Key Performance Indicators) бизнеса существуют?
Главная цель изучения открытых источников – максимально качественно подготовиться к дебютной встрече с заказчиком. Это нужно для того, чтобы настроиться с ним на одну волну и предложить нацелить проект на решение найденных нами проблемных зон.
Если же говорить о сроках подготовки к первой встрече с заказчиком, то количество затраченного времени может быть разным – от нескольких часов до нескольких дней – этот срок зависит от сложности задачи, отрасли и многих других факторов. В любом случае аналитик не имеет права ехать к заказчику, ничего о нем не зная. Он должен подготовиться хотя бы в минимально возможном объеме.
Обследование заказчика и работа с открытыми источниками
Этот этап начинается с первой установочной встречи с заказчиком, на которой мы стараемся выяснить его видение задач проекта, какие бизнес-процессы являются наиболее непрозрачными, какие зоны ему видятся проблемными и т.д. Далее мы продолжаем работу по исследованию и анализу, начатую на предыдущем этапе. Также к нашим данным добавляется материал, предоставленный клиентом, что расширяет диапазон нашей исследовательской работы.
Обычно требуется несколько встреч с заказчиком, в ходе которых мы пытаемся «снять» максимальное количество информации, необходимой для реализации проекта.
Когда объем полученной и проанализированной информации набирает некоторую «критическую массу», мы плавно переходим на следующий этап.
Наглядным примером одного из наших проектов является кейс «Управление кредитным портфелем коммерческого банка».
Кейс «Банки. Кредитные процессы»
Основной заработок большинства банков состоит в предоставлении кредитов компаниям и населению. Нам была поставлена задача мониторинга кредитов крупным компаниям-заемщикам.
В банках на каждую компанию составлен ее профиль, в котором содержится информация о надежности компании, ее финансовых показателях. По каждому кредиту отслеживается своевременность платежей. В случае просрочки очередного платежа банк выясняет причины просрочки и предпринимает действия в отношении компании-заемщика.
Основными идеями приложения для этой предметной области были: контроль объемов кредитов, надежности заемщиков, соблюдения графиков платежей и других показателей по кредитам.
Чем больше «плохих» кредитов в денежном выражении у банка – тем хуже качество кредитного портфеля. Поэтому руководству банка необходимо сразу видеть «плохие» кредиты, иметь возможность посмотреть подробную ситуацию по проблемному кредиту и принять решение по дальнейшим действиям в отношении компании-заемщика.
Работа с приложением в итоге становится чем-то похожа на игру «найди проблемный кредит и сделай его беспроблемным».
Читая статью дальше, попробуйте «примерить» этапы процесса анализа на эту предметную область. Думаю, что так читать будет гораздо проще.
Анализ, формирование требований и документирование
В действительности никакого перехода на этот этап не существует, работы этого этапа выполняются параллельно с работами предыдущего. Но я выделил его намеренно, чтобы весь процесс анализа выглядел пошаговым, более стройным и структурированным.
Итак, в рамках данного блока выполняются следующие активности:
- Брейн-штормы;
- Анализ информации и формирование требований;
- Рисование эскизов экранов приложения.
Когда аналитик проекта уже получил достаточно много информации о бизнесе заказчика, он организовывает совещание (брейн-шторм), на котором он и ведущие аналитики нашей компании придумывают основные идеи, которые будут положены в основу будущего приложения. После этого данные идеи глубоко прорабатываются, определяя этапы реализации. В итоге мы окончательно формулируем основную проблему бизнеса заказчика и решаем, на что будет нацелено наше приложение.
Далее определяем состав показателей, мониторинг и анализ которых поможет заказчику утолить его боль. Конкретизируем состав и структуру экранных форм, на которых заказчик будет работать с этими показателями.
Надо отметить, что мы создаем не «обычные» BI-отчеты, а трехмерные приложения. В этих приложениях визуализация аналитической информации выполняется в виде 3D-объектов, объединенных в тематические интерактивные сцены (экранные формы), связанные между собой логическими переходами. Текстом описывать их довольно сложно, поэтому предлагаю вам примеры экранных форм ряда приложений разной отраслевой принадлежности.
Поскольку мы разрабатываем трехмерные приложения, то в совещаниях участвуют не только аналитики, но и специалисты по инфографике, юзабилисты и 3D-дизайнеры. Они предлагают компоновки экранов, 3D-образы для визуализации данных заказчика, удобную навигацию между экранами и т.п. Таких брейн-штормов требуется несколько, в зависимости от сложности будущего приложения.
По результатам каждой из встреч аналитик проекта фиксирует все требования к будущему приложению в документе «Описание приложения». Его структура представлена в следующем разделе. Хочу обратить ваше внимание на то, что все результаты анализа обязательно должны тщательно документироваться, это очень важно.
Формирование итогового документа «Описание приложения»
Итак, что же включает в себя документ «Описание приложения»? Его структура достаточно проста:
- Постановка задачи и начало работы;
- Обследование заказчика и работа с открытыми источниками;
- Анализ, формирование требований и документирование;
- Формирование итогового документа «Описание приложения».
В разделе «Описание предметной области» мы фиксируем информацию о бизнесе, которая критически важна для формирования требований к будущему приложению. Этот раздел в обязательном порядке согласовывается с заказчиком, чтобы не допустить смысловых ошибок. Потому что, при их появлении, выводы из этого описания будут ошибочные и приложение в итоге необходимо будет переделывать.
Например, по результатам встреч с заказчиком мы зафиксировали несколько показателей, которые важны для мониторинга кредитов. После согласования этого раздела с другими подразделениями заказчика выяснилось, что часть этих показателей не важна для контроля кредитного портфеля, в то время как несколько важных показателей были упущены.
В раздел «Цели и задачи» выносятся идеи, которые мы сформулировали на брейн-штормах с коллегами и встречах с заказчиком.
Наконец, самый объемный раздел документа – «Описание решения». Он затрагивает следующие пункты:
- Перечень анализируемых показателей;
- Источники данных (информационные системы), из которых мы будем извлекать эти показатели;
- Структуру экранов приложения;
- Эскиз и текстовое описание каждого экрана приложения;
- Основные сценарии работы пользователя с приложением.
Про показатели и источники данных дополнительно писать нечего, с ними и так все понятно. Описание структуры экранов тоже сравнительно просто сделать, оно включает перечень экранов приложения и возможные переходы между ними.
Немного остановимся на эскизах. При формировании итогового документа «Описание приложения» эскизы выполняются нашими 3D-дизайнерами в графических редакторах и в средствах трехмерного моделирования. По эскизам будут потом создаваться экраны будущего приложения, причем они будут не «примерно такими же», а абсолютно идентичными нарисованным эскизам, без каких-либо отличий. Детально проработанные и прорисованные эскизы необходимы в документе, чтобы заказчик мог увидеть будущее приложение уже на начальной стадии проекта, хотя бы в виде экранов, и сформулировать свои замечания. Правки бывают как смысловые (например, не тот показатель отображен), так и в части визуализации (необходима другая цветовая палитра, другие элементы инфографики, показатели необходимо передвинуть в другую часть экрана и т.п.).
При разработке сценариев работы пользователя с приложением мы формируем от одного до 5 основных сценариев. Сценарии мы выбираем только те, которые пошагово ведут пользователя к достижению целей и к решению конкретных задач приложения. Если с помощью сценария мы удостоверились, что все цели достигнуты и все задачи решены – значит приложение спроектировано верно.
Итоговый документ «Описание решения» проходит несколько итераций согласования с заказчиком и его финальный вариант прикладывается к договору на выполнение работ. По этому согласованному документу продолжаются работы по проекту, а именно:
- Формирование постановки на визуальную часть приложения;
- Формирование постановки на загрузку и обработку данных приложения;
- Разработка 3D-компонентов;
- Верстка приложения;
- Тестирование и приемка приложения.
Но эти работы – предмет других статей. Данная статья посвящена только процессу бизнес-анализа в наших проектах.
Вместо заключения
В завершение хочу назвать несколько принципов, которых стоит придерживаться при разработке приложений.
Их всего три:
- Наглядное представление картины бизнеса заказчика. Уже при первом знакомстве с приложением на экране пользователь должен увидеть все интересующие его части своего бизнеса, при первом же контакте понять, какие зоны проблемные, а какие функционируют без отклонений. Представленная информация должна быть интуитивно понятна руководителю, для которого время – дефицитный ресурс. У него нет возможности проходить длительное обучение: трактовке цифр, визуальных объектов на экране и т.д. С помощью интерактивной визуализации мы достигаем интуитивно понятного представления данных в разных разрезах. При этом работу с приложением мы строим через сенсорный экран, который обеспечивает больший комфорт, эргономичность и, что самое важное, вовлечение пользователя в процесс анализа.
- Раскрытие причин проблемы. Выбрав проблемную точку, пользователь должен иметь возможность воспользоваться функцией drill down, которая позволяет провалиться глубже в проблемную зону, на следующих экранных формах увидеть причины возникновения отклонений. Кроме того, приложение должно предлагать пользователю возможные варианты локализации проблем.
- Техническая эстетика. Приложение должно вызывать вау-эффект т.е. должно быть привлекательным, интуитивно понятным и удобным. Эти аспекты, по нашему убеждению, должны занимать равноправную позицию наряду с функциональными составляющими.
Перечисленные принципы достаточно просты, но соблюдая их, нам удается создавать интересные решения, которые приносят пользу нашим заказчикам.
Пожалуй, добавлю еще несколько картинок, чтобы вы понимали, как могут выглядеть подобные приложения и в каких отраслях применяться.
Спасибо, что дочитали до конца. Наверняка у вас появились при прочтении вопросы. Готов ответить на них в комментариях. Пишите!
Автор: boyarskiy
