Как грамотно провести реинжиниринг отчетности: предпосылки и задачи
Отчетность – неотъемлемая составляющая бизнес-систем в каждой компании, и ее обновление считается долгим и трудозатратным проектом. Как реализовать его оптимально – рассказывает руководитель практики BI в компании iFellow Павел Осипов.
Отчетность в каждой компании может быть самой разнообразной: как стандартизированные отчеты для предоставления в государственные службы, так и самые разнообразные отчеты для внутренних нужд. Их используют практически все офисные сотрудники – от руководителей до рядовых специалистов. В связи с увеличением роли отчетности в деятельности компаний и развитием технологий автоматизации большую востребованность получили BI-аналитики и соответствующие цифровые инструменты Business Intelligence. Они отвечают за преобразование накопленной в хранилищах компании информации в понятные для восприятия форматы – например, в отчеты, дашборды или отдельные диаграммы.
Предпосылки к реинжинирингу отчетности
Реинжиниринг отчетности – это обновление или модернизация ее методик и инструментов. Таким образом, процесс реинжиниринга подразумевает, что некий набор отчетов и некая методология их создания и управления ими в компании уже есть. Отчеты могут накапливаться много лет: собираться несколькими командами, использоваться разными бизнес-юнитами, периодически дорабатываться, исправляться, устаревать – но по формату оставаться прежними. Какие же предпосылки диктуют необходимость кардинальных изменений в этом процессе?
Первый сценарий реинжиниринга возникает, когда компания достигает более высокого уровня зрелости. До определенного момента для всесторонней отчетности и аналитики ей вполне достаточно нескольких Excel-файлов со сводными таблицами и графиками. Но в результате развития бизнеса Excel перестает справляться со всеми задачами. У компании появляется потребность в одновременном использовании отчетов разными представителями бизнеса, в обновлении данных по расписанию, в разных схемах сборки этих данных для разных категорий сотрудников и т. д. Требуется переход на профессиональную BI-систему.
Второй сценарий связан с тем, что владельцам уже развитой системы отчетности становится сложно управлять существующим пулом отчетов. Это случается, когда, например, компанию покинули разработчики, создавшие систему, новым специалистам проблематично в ней что-то изменять, эффективно ее вести и поддерживать. Бывает, что невозможно определить заказчиков отчетов, на отчеты нет технической документации. Как итог – система в существующей конфигурации становится неуправляемой.
Третий сценарий наиболее актуален сегодня для российских компаний: он связан с уходом из страны западных вендоров BI-систем, с невозможностью полноценно использовать и поддерживать такие продукты, как Tableau, Qlik, Power BI. Компании остается доступен функционал создания и публикации отчетов, но вносить какие-то «подкапотные» правки в систему собственными силами она уже не может. В этом случае также надо задумываться о смене инструментов.
Подготовка к реинжинирингу отчетности
Как и в случае любого инженерного техпроцесса, на эффективность реинжиниринга отчетности сильно влияет подготовительный этап – когда стоимость потенциальной ошибки (например, неправильного выбора отчетов или инструментария для реинжиниринга) намного ниже.
Первый шаг, который необходимо сделать руководителю данного проекта – провести опрос всех заинтересованных сторон, например: какие из существующих в компании отчетов нужны и важны, какие отчеты нужны, но не очень важны и т.д.
Такой опрос можно организовать в любой удобной форме: очные беседы, бумажные анкеты, Google Forms, дашборд в Miro и т. д. В результате вы классифицируете всю отчетность и выделяете неактуальные отчеты – категорию, реинжиниринг которой не имеет смысла. Это могут быть, например, отчеты, которыми никто не пользуется, но которые по какой-то причине продолжают обновляться и нагружать систему.
Второй шаг – выбор нового технологического стека, на который будут переноситься отчеты. В привычном смысле BI-система представляет из себя хранилище данных, ETL-процесс и отчетность. Однако каждый раз ситуация перед проектом может быть индивидуальная. Например, если в компании изначально отсутствует полноценное хранилище данных, данные собираются не структурировано, особое внимание стоит уделить именно этому аспекту. Если используются устаревшие инструменты ETL, необходимо изучить современные продукты, доступные на рынке.
При реинжиниринге отчетности в iFellow было принято решение поначалу спроектировать и структурировать новое хранилище данных, разобрать все бизнес-сущности, отстроить все схемы и нарисовать модель данных компании. И только после этого команда постепенно начала эту схему воплощать, реализовывать в новом хранилище. Мы использовали стек из хранилища PostgreSQL, Apache Airflow, Python для ETL и Power BI для визуализации. Этот стек сегодня считается наиболее актуальным и быстрым как с точки зрения скорости работы, так и с точки зрения реализации. Дополнительно, если говорить уже про расширенные возможности Big Data, в этот стек войдут такие продукты, как Greenplum, совокупность инструментов Hadoop и другие инструменты параллельных вычислений.
Стек надо выбирать с учетом развития системы, то есть предусматривать масштабируемость. Ведь с появлением профессионального BI запрос на него в компании всегда начинает расти. Поэтому в проект нужно закладывать такие факторы, как рост потребностей, потоков данных, области и периода хранения. Кроме того, выбор стека стоит проводить с учетом санкционных рисков и возможностей импортозамещения. Есть смысл изучить перспективные отечественные решения и продукты из категории opensource.
Третий шаг – оценка собственных мощностей: команды и инфраструктуры. Качественный реинжиниринг часто подразумевает увеличение сложности работы с системой отчетности. Возможно, придется переструктурировать данные, изменить состав команды разработчиков отчетности, провести короткое, но нагруженное обучение работе с новыми инструментами.
Четвертый шаг – приоритизация. Мы уже отфильтровали совсем ненужные отчеты, но остались другие категории, которые нужно ранжировать по степени важности для компании. Для этого, как правило, создается технический комитет и проводятся регулярные встречи с представителями пользователей отчетов: финансового, коммерческого, операционного департамента и т. д. в зависимости от структуры компании. В результате совместного определения приоритетов будет определена последовательность реинжиниринга каждого отчета.
Выстраиваем процесс реинжиниринга
Реинжиниринг конкретного отчета представляет из себя уже более логичный и структурированный процесс: из утвержденного пула вы берете первый отчет и поручаете разработчику переделать его на новом стеке. К этому этапу важно подключить аналитика, который станет связующим звеном между разработчиками и бизнес-заказчиком. Аналитик будет фиксировать функциональные и нефункциональные требования, мониторить, устраивает ли заказчика текущий внешний вид и функционал отчета, получать от него правки от косметических до смысловых, на основе полученной информации писать ЧТЗ – частные технические задания. По нашему опыту, при наличии ЧТЗ разработка отчета при реинжиниринге ускоряется в 2-3 раза.
Сама разработка происходит вариативно, в зависимости от того, какой сценарий реинжиниринга используется в компании, какой стек технологий выбран, какие задачи в целом стоят. Например, в случае iFellow нужно было сначала оценить наличие необходимых данных в хранилище, а потом их достаточность. Если их недостаточно, завести эти данные в хранилища, нормализовать их, структурировать, расписать на бизнес-сущности, сформировать витрины данных для отчета и только после этого подключить отчет к новому хранилищу. В другом проекте, возможно, не нужно будет переделывать хранилище или организовывать ETL. Иногда достаточно перенастроить время обновления, завести пару дополнительных атрибутов. Всё зависит от изначального состояния системы и пожеланий бизнеса. В этом процессе важно постоянно поддерживать связь с заказчиком, интересоваться тем, как он оценивает промежуточный и финальный результат.
На завершающем этапе, когда команда успешно переделала отчет, ей необходимо произвести сверку данных, после чего публикацию и презентацию отчета бизнес-заказчику. В этот момент снова требуется помощь аналитика. Важно провести некий «онбординг» отчета, например, его бета-тестирование в реальных условиях на ограниченном круге пользователей. После этого можно собрать первый фидбэк, получить правки, которые решаются за один спринт. После принятия всех правок отчет выпускается в релиз и ставится на поддержку.
В случае, когда подразумевается полная трансформация, включая создание хранилища, ETL, перенос старых отчетов на новый стек, – на реинжиниринг одного отчета первоначально стоит закладывать примерно две недели. Это при условии, что в команде один разработчик, один инженер (который добавляет данные в хранилище) и один аналитик. Со временем этот срок будет уменьшаться, потому что на начальном этапе в хранилище нет вообще никаких данных, а спустя 3-5 месяцев их уже много, и можно эти данные переиспользовать. Когда процесс станет более понятным и оптимизированным, постепенно будет сокращаться нагрузка на инженера, а потом и на аналитика. Например, в команде iFellow сегодня проектом занимается один BI-разработчик, который переносит отчет самостоятельно за одну неделю.
На эффективность и длительность процесса реинжиниринга, таким образом, влияет первоначальное состояние системы отчетности, предпосылки к переносу, выбранный стек технологий, бизнес-требования. И очень многое зависит от команды. Если это высококлассные специалисты, то реализация проекта занимает гораздо меньше времени.
