Привет, Хабр! Сегодня мы будем говорить о лучших практиках внедрения BI, а точнее об интересных лайфхаках, изложенных в методологии компании Anaplan. В этом посте я постарался рассказать, почему важно бронировать время топ-менеджеров, как обеспечить соответствие проекта ожиданиям, почему Agile оказывается полезен и в сфере BI, а также, как сделать систему удобной для конечных пользователей. Если вы имеете опыт реализации BI-проектов или планируете им заняться, давайте вместе обсудим методику внедрения от Anaplan!
Чтобы не набивать шишек на стандартном пути внедрения BI, я считаю, можно и нужно пользоваться чужим опытом. Ведь столько проектов уже было похоронено под грузом неверных процессов, и столько раз опытные ребята вывели для себя правила, как избежать типовых проблем.
На своем опыте я убедился, что многое можно взять из разработк ПО. Ведь в конечном счете, именно на него похоже внедрение проекта BI (причем чем сложнее система, тем больше похоже). И тот факт, что стоимость ошибки в начале , особенно на фазе сбора требований, ниже, чем на более поздних этапах, является общим как для софтверной разработки, так и для внедрения BI.
Чем дальше от начала проекта, тем больше сил мы вложили во что-то неправильное, и тем дороже будет стоить ошибка, причём экспоненциально. Говоря проще, если мы в самом начале поленились сходить к бизнес-заказчику, чтобы показать какой-то прототип, и не получили важной информации о том, что “вот эта кнопка на самом деле не нужна, а вот этот график на самом деле очень нужен”, то правки будут стоить больших ресурсов. Особенно, если мы это всё уже запрограммировали, сделали ETL, подготовили дашборды. Цена ошибки может быть в 100 раз выше!
Я, конечно не хочу сказать, что любой маленький дашбордик нужно прогонять через весь цикл разработки ПО. Но, тем не менее, для каждого этапа проекта требуется достаточное документирование и тестирование должно быть. И, что важно, проект не заканчивается со сдачей работы. Тут точно так же, как с разработкой софта: мы его доделали, выдохнули и отдали пользователям…и в некоторых случаях на таком этапе можно констатировать выполнение работ на 20% работы. Дело в том, что в BI технологии и внедрение — это только ⅕ успеха. Остальное определяют культура, процессы, команда и бизнес-кейсы. И чтобы обеспечить соответствие лучшим практикам для всех 100% проекта, существует немало методологий. Об одной из них я хочу поговорить сегодня — это Anaplan Way, который предлагает известный поставщик аналитических решений для финансовой сферы, компания Anaplan.
It’s Anaplan Way
Anaplan Way — это стостраничный документ, в котором очень подробно написано, что и в каком порядке нужно делать для внедрения. Дополнительный плюс Anaplan в том, что они еще и предлагают специальный инструмент, который помогает управлять проектом. В результате получилась целая web-система управления проектами, в которой можно распланировать задачи, мониторить их исполнение и так далее. Все это можно делать на основе уже готовых шаблонов….но только если вы внедряете Anaplan. Однако сама методология вполне подходит и для внедрения других систем.
Методология Anaplan подразумевает 4 краеугольных камня внедрения: процессы, данные, моделирование и развертывание.
Под процессами авторы подразумевают именно внедрения решения. Термин “моделирование” означает работы по настройке самой системы Anaplan (ну или аналогичного -решения). “Данные” включают в себя выгрузку, преобразование и очистку. А “развертывание” — это окончательный этап, после которого происходит переход к продуктивной работе.
Интересна также статистика распределения времени между этими элементами процесса внедрения. “Данные”, конечно, занимают большую часть времени (и это нормально — у всех и всегда так). Но на моделирование и непосредственно разработку системы в методологии Anaplan отводится всего 17%, а на управление процессами — встречи, планирование, проектирование и так далее — 35%. На большинстве проектов, с которыми я сталкивался в крупных и средних организациях (может быть и с малым бизнесом все так же, но там мы практически не работаем), на планирование, наоборот, приходится 20%, а то и 15%. Основное время отнимает разработка. И я согласен с мэтрами из Anaplan — такой подход не всегда хорошо влияет на результаты.
Фазы проекта
Anaplan Way подразумевает 5 фаз проекта:
Предпроектная фаза — она нужна для первоначальной оценки, сначала грубой, а потом — более точной. На этом этапе мы фактически пишем ТЗ на проект.
Фаза инициации — пожалуй, самая интересная часть. Она подробно описывает процесс запуска проекта. И ее наличие подразумевает, что мы не сразу “бежим” разрабатывать решение, а сначала инициируем его
Фаза реализации — собственно, разработка проекта
Фаза тестирования — проверка гипотез на реальных данных и в реальной ситуации
Фаза развёртывания — начало работы конечных пользователей с системой, то есть продуктивная эксплуатация.
Предпроектная фаза
В этой фазе выполняется оценка проекта. И, наверное, самый важный артефакт методологии Anaplan на данном этапе — чёткое описание тех встреч, необходимых для правильного старта, и сессий, которые нужно провести для сбора достаточного количества требований к старту проекта. Например, эксперты утверждают, что грубая оценка должна выполняться за 2 рабочих дня, в которые входит наличие сессии от часа до целого дня с непосредственным участием заказчика. Продуманный подход к предпроектной подготовке помогает задать более четкий вектор проекту.
Фаза инициации
На этапе инициации проекта идеологи Anaplan предлагают интересную мысль — начать с написания манифеста проекта. По задумке авторов он пишется совместно со стейкхолдерами самого верхнего уровня, которые фактически непосредственно заинтересованы в результатах проекта. В написании манифеста может принимать и генеральный директор, и акционеры, и руководители определенного направления.
Однако не стоит рассчитывать, что стейкхолдер действительно сам напишет свои ожидания. Методология говорит, что необходимо сесть вместе с ним и написать короткое “эссе” буквально из 1-2 абзацев. Например, подобный манифест может выглядеть следующим образом:
“Мы хотим получить систему финансового анализа, благодаря которой генеральный директор ежедневно сможет отслеживать чёткие и актуальные данные, не дожидаясь закрытия квартала еще 20 дней, а принимать решения сегодня и сейчас”.
Очень важно, чтобы по завершении проекта манифест позволял понять, достигли мы озвученных целей или не достигли.
Ещё это очень важно для привлечения заказчиков высокого уровня в самом начале, потому что очень часто так происходит, что этим людям достаточно трудно найти время, чтобы провести такую сессию. И очень часто проекты начинаются без этого. И тогда это просто проблема — формулирование целей проекта, она переносится на более поздний срок, а то, что было сделано до этого, часто переделывается. Поэтому обязательно, конечно, это надо делать.
Какие ещё идеи важные? Первое — это keep it simple, то есть фокус на каких-то малых и простых вещах. То есть мы сразу говорим заказчикам (под заказчиками я подразумеваю бизнес-заказчика сейчас), что мы фокусируемся на понятных, простых результатах. Если мы в рамках этого проекта не можем, не понимаем ещё, как их достичь, то, соответственно, мы можем это просто перенести на более поздний срок. Часто я видел, как в ТЗ написано, например, «по результатам проекта должны применяться методы машинного обучения для анализа факторов, влияющих на прибыль». Это очень размыто на самом деле, и очень большая история. Если она написана одним предложением, то скорее всего мы её не достигнем, поэтому фокусируемся на малых вещах.
Фаза инициации также подразумевает сбор данных по процессу. В методологии Anaplan для этого предусмотрена “встреча на целый день”. Поэтому необходимо донести бизнес-заказчику, что мы не закончим за полчаса или час. Возможно после целого дня работы еще будут дополнительные коммуникации по этому вопросу. Формирование ожиданий по выделению времени на подготовку — очень важный этап, с которым связана масса проблем на реальных проектах. Когда у ответственных лиц заказчика не сформированы ожидания по временным затратам, они это время (естественно) не выделяют, а проект, соответственно, буксует.
В рамках этой же фазы формируется команда. И тут снова важно обеспечить выделение времени, причем не со стороны консультанта (он на этом зарабатывает) и не со стороны IT-команды (которая и так внедряет), а со стороны бизнеса. Главному ответственному лицу от бизнеса необходимо выделять порядка 10 часов в неделю, руководителям проекта по 15 часов в неделю, а аналитикам — то есть людям, которые будут непосредственно работать над дашбордами и моделями данных, требуется 30+ часов в неделю — то есть фактически full-time! На разных фазах также могут потребоваться эксперты, для которых Anaplan рекомендует предусмотреть временные затраты порядка 25 часов в неделю. Как видите, мы говорим о серьезном выделении времени. Конечно, в зависимости от типа проекта конкретные показатели могут здорово отличаться, но в любом случае все это надо обсудить с командой еще на старте.
Ещё одна очень классная идея заключается в том, что обучение заказчика, в том числе техническое, должно проводиться до сбора требований, а не как это обычно делают — когда систему уже готовят к внедрению. В этом случае люди знакомятся с принципами работы системы, хотя бы на пальцах. Они понимают, как примерно она работает, и какие требования в ней можно реализовать, а какие — нет. Такой подход помогает значительно поднять эффективность проекта и обсуждения требований, потому что иначе из-за неправильно сформированных ожиданий постановка задачи часто напоминает разговор слепого с глухим: люди просто не очень понимают друг друга, и в результате бизнес-заказчики получают не то, что они хотели.
Кроме этого коллеги из Anaplan рекомендуют создавать центр компетенций сразу, то есть в самом начале реализации первого BI-проекта. Причём в методологии написано, что раньше они рекомендовали создать центр компетенций только в крупных проектах, а сейчас всё это стало must have в любом проекте. Центр компетенций — это либо отдел, либо рабочая группа, в которой присутствуют навыки и знания в сфере IT, аналитики, а также бизнес-процессов. Перед центром компетенций длолна быть чётко поставлена задача, что именно они отвечают за BI, именно они отвечают за аналитику или суть конкретного проекта. Ребята должны понимать, что сейчас они — рабочая группа, но когда проект успешно реализуется, они станут отделом и будут развиваться вместе с проектом. Такая группа поддержки обеспечивает проекту стабильность и осознанность, помогает ему решать реальные задачи бизнеса, используя весь потенциал внедренного решения.
В качестве единицы планирования Anaplan предлагает использовать пользовательские истории. Если вы не сталкивались с таким термином, речь идет о способе описывать задачи следующим образом: «Я, как финансист хочу вносить правки в управленческую отчётность для того, чтобы повысить точность квартальных прогнозов». В пользовательской истории есть 3 основных пункта — роль, действия и их цель. В отличие от описания конкретных фичей, пользовательские истории позволяют гибко, в принципе, управлять развитием проекта, оставляя за разработчиками и аналитиками выбор, как реализовать ту или иную историю. Ребята из команды внедрения в результате понимают, зачем они реализуют тот или иной график, и, как следствие, делают работу более качественно с точки зрения конечного пользовательского опыта.
Пользовательские истории предполагается делить на 3 корзины по приоритетам сразу, еще до старта проекта. Четвёртая или дополнительная корзина собирает все необязательные пожелания, например, «давайте сделаем покрасивее шрифты». В фазе реализации, которая выполняется короткими двухнедельными итерациями, происходит оценка результата, и каждый раз принимается решение, какие именно истории брать на следующую итерацию в соответствии приоритетами корзин. Если на первой итерации появились замечания типа «а давайте эту кнопку перекрасим », задачу кладут в самую последнюю корзину и реализуют в последнюю очередь, если остается время. Очень важно обсудить этот подход с заказчиком в самом начале, чтобы приоритеты были понятны и прозрачны. В результате стейкхолдеры не будут думать, что команда не хочет “перекрасить кнопку”, ведь нам всем важно, чтобы первые приоритеты были решены в первую очередь, иначе вообще весь проект может “не взлететь”. Я на своей практике убедился, что при четком взаимопонимании подобная система нормально воспринимается и специалистам как со стороны исполнителя, так и со стороны заказчика, оказывается проще работать.
Для проведения оценки коллеги предлагают использовать еще один стандарт из мира разработки ПО — это planning poker. На карточках указывается сложность задачи, причём нелинейная, потому что человеку на самом деле сложно проводить линейную оценку. Мы можем легко прикинуть, займет задача час или два, но разницу между 21 часом или 22 часами человек оценить уже не может. Поэтому на карточках указывается порядок — 1 час, 5 часов, 10, 20, 40 и так далее.
Про planning poker можно многое прочитать в интернете. Однако важнейший плюс этого подхода в фазе инициации заключается в том, что он позволяет получать информацию об оценке трудозатрат даже от глубоких интровертов, которые и на совещаниях-то чаще всего молчат.
Система работает так: все выкладывают карточки в закрытую, потом одновременно вскрывают и изучают оценки. Тех, у кого самая большая или самая маленькая оценка спрашивают, почему так много или почему так мало. Благодаря этому люди делятся информацией, которая позволяет значительно уточнить оценку. Также большой плюбс в том, что в оценке принимает участие вся команда, а не только РП, которому приходится многие вещи брать прямо “из головы”. Поэтому planning poker увеличивает точность планирования.
Фаза реализации
По мнению Anaplan базовая методология реализации — это Scrum, одна из agile-методологий разработки ПО, про которую тоже можно почитать подробнее в бесчисленном количестве постов на одном только Хабре. Но самое важное в нашем случае то, что Scrum задает фокус на коммуникациях и на итеративной разработке.
Процесс внедрения новых фичей идет итерациями по 2 недели. Внутри этих итераций происходит активная коммуникация. На ежедневных стендапах по 5 минут вся команда делится тем, что за день получилось или не получилось. В конце каждого спринта происходит ревью и демонстрация результатов заказчику. В результате уже через первые две недели бизнес-спонсор может дать обратную связь, которую можно учесть в разработке.
При этом, конечно, очень важно управлять эмоциями и ожиданиями заказчика. Я сам лично много раз слышал, что “у нас в России так нельзя”, “у нас госконтракт” или “у нас огромный контракт с огромными финансами, и мы должны работать по водопадной модели”. Коллеги, уверяю, ничего не мешает работать по водопадной модели, а внутри больших итераций делать спринты. Кстати, Anaplan также пишет, что заказчикам, которые не привыкли работать со Scrum и вообще по Agile-методологии, первые два спринта будет действительно некомфортно. Но когда они увидят по итогам второго спринта уже реально работающие вещи, поймут, что их требования были учтены, новую методологию поддержат и в будущем будут стремиться вести проекты только так.
На этапе реализации проекта много приходится работать с данными. И тут Anaplan рекомендует: «Будь детективом!». Ведь на самом деле ничему и никому нельзя доверять просто так. Когда со стороны заказчика говорят: «У нас тут в 1С есть чистые данные по проектам, вы их просто заберите и всё», значит данные точно надо проверить! Причем точек проверки должно быть как минимум 3: нужно спросить у бизнеса, задать вопросы IT, а ещё своими глазами посмотреть. Только в этом случае можно быть уверенными в том, что данные действительно подходят. Я лично видел проекты, которые на годы срывались из-за того, что в начале не было проведено достаточно проверок качества данных.
Разработчики ETL очень любят начинать автоматизировать быстрее. Им это сделать проще. Но на самом деле какие-то данные можно просто взять, вручную обработать их в Excel или подготовить на Python, чтобы положить на дашборд. В результате после очередного спринта можно получить обратную связь от бизнеса. Благодаря этому можно исправить все ошибки и не тратить лишнего времени на повторую автоматизацию аналитики, потому что первичная оказалась “не о том”.
Следующий важный аспект внедрения — это выбор архитектора. Для построения модели необходимо участие опытного человека. Когда мы формируем архитектуру решения, очень важно, чтобы человек, который это делает, мог предусмотреть различные ситуации. Опытный архитектор нужен для того, чтобы нам не пришлось все переделывать просто потому, что выбранная модель перестает соответствовать требованиям производительности, когда системой начинает пользоваться 100 человек или когда в нее добавляют ещё 10 источников данных.
И, наконец, самое важное на этапе внедрения — это вовлечение конечных пользователей. По методологии Anaplan делать это надо не позднее второго спринта! Здесь речь идет не про бизнес-консультантов и менеджеров, которые приходят и рассказывают, как все должно выглядеть, а про тех конкретных людей, которые будут с системой работать в конечном итоге. Если вы вели проекты в сфере BI, то уже знаете, что пользователи смотрят на всё по-другому, и они будут давать иную обратную связь. Вовлекая их на раннем этапе внедрения, мы можем избежать отторжения на этапе развёртывания, а также лишних затрат на переделывание интерфейса.
Фаза тестирования
Говоря о тестировании, эксперты Anaplan отмечают, что тесты надо писать на ранней стадии. Нужна программа или «методика испытаний». Чтобы проверить, что все это действительно работает, нужно предусмотреть процесс тестирования для каждой из функций.
Также тесты требуются для проверки производительности. У Anaplan, как и у каждого вендора, есть конкретные критерии потребностей в нагрузочном тестировании. Например, в той методологии, о которой мы говорим сегодня, нагрузку нужно проверять, если речь идет более, чем о миллиарде ячеек. В других системах эти значения могут отличаться. Например, мы в Visiology
Фаза развёртывания
На этом этапе методология Anaplan предлагает делать достаточно очевидные вещи. Нужно добиваться поддержки пользователей за счёт четкого плана коммуникаций и программ обучения. Команде внедрения нужно следить за тем, что системой действительно пользуются. А на контакте с пользователями — убедиться в том, что заявленные цели и пользовательские истории реализуются именно так, как и ожидалось.
В мануале Anaplan даже написано, что ответственный со стороны команды реализации должен проверить удовлетворённость клиента через 30, 60 и 90 дней после внедрения. Мне кажется, это очень правильная и классная практика.
Заключение
В этом посте мы прошлись по методологии внедрения BI от компании Anaplan. Лично для меня знакомство с этим документом было весьма полезным и познавательным. И многие из позиций коллег мы используем сегодня и в своих лучших практиках внедрения BI. Кстати, будет здорово, если вы поделитесь в комментариях своим мнением об этой методологии. Если у вас есть свои интересные наработки, также делитесь опытом. Может быть он поможет кому-то добиться большего от текущих проектов. В частности, сами специалисты по Anaplan утверждают, что по этой методике проекты комплексного финансового планирования и аналитики внедряются очень быстро, всего за 2-3 месяца.
При этом нужно учитывать, что Anaplan — это не самая функциональная система из числа доступных на рынке BI-решений — все-таки ребята в первую очередь сфокусированы на финансовой аналитике only. Поэтому методики других компаний в части разработки и тестирования могут оказаться интересным дополнением. И в следующем посте я буду говорить о методологиях Qlik, PowerBi и Tableau. Так что подписывайтесь на наш блог, если вы этого еще не сделали.