Русский
Русский
English
Статистика
Реклама

Power bi

Как селф-сервис BI убивает кровавый энтерпрайз

15.02.2021 10:17:19 | Автор: admin

Привет, меня зовут Владимир Шилов, я руководитель направления в департаменте анализа данных Ростелекома. В мае 2019 года я пришёл в команду Business Intelligence (BI) и одной из первых задач была реализация отчётности по анализу посещаемости отчетов во всех BI-инструментах, установленных в компании.

Решение этой задачи позволило собрать любопытную статистику и сделать выводы о востребованности BI-инструментов в Ростелекоме. В этой статье я хочу поделиться следующими результатами нашего анализа:

Какие BI системы наиболее востребованы в реалиях крупной компании;
Какие критерии влияют на внутреннюю популярность решения;
Какие современные тенденции пользовательского поведения можно наблюдать внутри компании и какие вопросы будут стоять перед ИТ-подразделениями в ближайшее время.

С чего всё началось: реализация решения по анализу используемости BI систем

Начну с общего описания ситуации и подходов к сбору информации. У нас в компании целевыми BI-системами являются:

1. Oracle BI
2. Microsoft analysis services
3. Microsoft Power BI
4. Qlik Sense
5. Форсайт

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

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

1. Провести анализ логов BI-систем по запуску отчётов;
2. Спроектировать модель витрины данных;
3. Разработать ETL;
4. Реализовать отчет в Power BI;

Решение получилось примерно следующим:

Числа в зелёных стикерах обозначают общее количество инсталляций, в синих количество self-service инсталляций.Числа в зелёных стикерах обозначают общее количество инсталляций, в синих количество self-service инсталляций.

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

Для начала предлагаю рассмотреть каждый BI-инструмент в отдельности.

Oracle BI

На Oracle BI реализовано подавляющее большинство отчётности в виду того, что Oracle BI является самым старым инструментом и у него почти не было альтернативы очень долгое время. Ниже представлены графики динамик по следующим показателям:
Количество используемых уникальных отчётов за период;
Количество уникальных пользователей.

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

Analysis services

Microsoft Analysis services в компании это тоже достаточно распространённый инструмент, что во многом обусловлено удобной для пользователей работой в Excel. Именно этот инструмент получил наибольшее распространение в компании: он даже более популярен в МРФ (макрорегиональных филиалах), чем в корпоративном центре. Это можно увидеть на следующей диаграмме по уникальным пользователям в разрезе территорий за последние 12 месяцев:

Ниже представлены графики динамик по следующим показателям:
Количество используемых уникальных OLAP-кубов за период;
Количество уникальных пользователей.

Рост количества используемых OLAP-кубов за последний год не наблюдается, а рост аудитории в BI-системе нестабильный со значительными всплесками. У такой статистики несколько причин:
OLAP-кубы в основном дорабатываются, а новые кубы появляются очень редко;
BI-система больше предназначена для аналитиков, умеющих работать с данными, и она сложно продается широкой аудитории;
Доступ к отчётности требует согласования с владельцем OLAP-куба.

Power BI

BI-система Power BI от Microsoft появилась самой последней в стеке инструментов компании, но именно к этой системе сейчас приковано самое большое внимание со стороны бизнеса по следующим причинам:
Базовый набор визуализаций имеет хороший дизайн;
Лицензирование осуществляется по ядрам на сервере, отсутствует лицензирование по пользователям;
Скорость разработки отчётов довольно высокая, но стоит отметить, что на полный цикл разработки это не сильно влияет.

Ниже представлены динамики показателей аудитории и количество отчётов, которые она использует:

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

Qlik sense

Qlik sense была первой корпоративной BI-системой с возможностью реализации полноценных дашбордов. Именно с Qlik sense связан переход от предоставления табличных данных к графическим визуализациям в компании.
Ниже представлены графики динамик по следующим показателям:
Количество используемых уникальных отчётов за период;
Количество уникальных пользователей.

Казалось бы, перед нами современный BI-инструмент с высоким спросом, в котором можно создавать красивые решения, но сильного роста отчётности по сравнению с Oracle BI и Analysis services мы не наблюдаем. Тут есть несколько причин, влияющие на аудиторию и количество новых отчётов:
Лицензия на одного пользователя стоит существенных денег, и поэтому бизнес отказывается заказывать отчетность в Qlik sense;
Длительный период реализации отчётов от подготовки данных до реализации не позволяет быстро перенести все бизнес-процессы на новый инструмент.

Теперь поговорим про инструменты Self-service.

Self-service инструменты

Qlik sense self-service

В ноябре 2019 для бизнеса мы развернули self-service и предложили бизнесу реализовывать свои отчеты на своих источниках самостоятельно. С точки зрения лицензирования было одно изменение разработчики лицензируются отдельно. С лицензиями пользователей изменений не было по причине того, что сервера были объединены в один кластер и лицензии, соответственно, тоже.
Графики динамик количества запускаемых отчётов и уникальных пользователей в недельной динамике представлены ниже:

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

Power BI self-service

Вот мы и дошли к самому интересному. Power BI self-service появился примерно в то же самое время, что и Qlik Sense self-service, но у данных систем есть одно существенное отличие в лицензировании. Для подключения команды разработчиков от бизнеса в Power BI self-service надо разово заплатить за лицензию на 2 ядра, что примерно равняется 35 лицензиям пользователей в Qlik sense, но лимита на пользователей в Power BI нет.

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

Ещё более наглядно всё выглядит если показать все рассматриваемые системы вместе:

Какие критерии влияют на развитие отчетности?

В части развития отчетности в BI-системах стоит выделить следующие особенности, которые описаны в таблице:

Свойство\BI-система

Power BI

Power BI self-service

Qlik sense

Qlik sense self-service

Analysis services

Oracle BI

Лицензирование

Бесплатно для бизнеса

Лицензия на 2 ядра на одну команду разработки. Для пользователей бесплатно.

Лицензия на каждого пользователя

Лицензия на каждого пользователя и разработчика

Бесплатно для бизнеса

Бесплатно для бизнеса

Вид визуализации

Дашборды

Дашборды

Дашборды

Дашборды

Excel таблицы

Табличные отчеты без аналитики

Требования к квалификации BI-разработчика

Низкие

Низкие

Средние

Средние

Средние

Выше среднего

Качество дизайна базовых визуализаций

Высокое

Высокое

Среднее

Среднее

Отсутствует

Низкое

Процесс подготовки данных

Централизованное хранилище

Собственные источники

Централизованное хранилище

Собственные источники

Централизованное хранилище

Централизованное хранилище

Предоставление доступа

Все отчеты публичные

Все отчеты публичные

По согласованию владельца лицензий

По согласованию владельца лицензий

По согласованию владельца куба

По согласованию владельца области предметной области

Исходя из результатов нашего анализа именно критерии, описанные в таблице, оказали самое большое влияние как на скорость создания новой отчетности, так и на востребованность отчетности пользователями компании. А ключевым фактором успеха Power BI self-service стала политика лицензирования и его условная бесплатность для разработчиков на стороне бизнеса.

Заключение

Из выше сказанного можно сделать вывод, что ключевыми факторами по использованию отчётности в различных BI-системах являются (расположены по мере уменьшения значимости):
Стоимость подключения новых пользователей, особенно на большую аудиторию;
Длительность полного цикла реализации отчёта от подготовки данных до публикации;
Простота реализации отчётов в BI-системе.

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

Несмотря на то, что у ИТ сейчас нет однозначных ответов на эти вопросы, очевидно, что бизнес уже сделал свой выбор в пользу Self-service инструментов, и на эти вопросы нам придется отвечать. Будем рады присоединиться к обсуждению в комментариях. О том, какие решения мы нашли для self-service контура Ростелекома мы расскажем вам в наших будущих статьях.

Статья подготовлена командой управления данными Ростелекома

Подробнее..

Аналитический отчёт застройщика как выглядит и как поможет в работе

06.04.2021 14:13:41 | Автор: admin

Отчёт застройщика опродажах имаркетинге часто связан струдностями сбора, сводки, аналитики ипредставления данных.

Застройщики сталкиваются стакими проблемами:

  • разрозненные данные вотчётности;

  • беспорядок вCRMи, как следствие, потеря лидов;

  • при масштабировании бизнеса иотдельных проектов теряется контроль над тактическими задачами;

  • человеческий фактор впроцессе обработки информации приводит кпотере данных;

  • нет единой системы бизнес-аналитики.

Застройщикам важно видеть, что происходит накаждом уровне воронки продаж, как работает каждый офис икаждый менеджер.

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

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

Мыразработали динамический отчёт застройщика вPower BI.

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

Сводный отчёт

Сводный отчёт по всем объектам дашборд для топ-менеджеров. Он показывает ситуацию по продажам в целом.

Сверху набор карточек с ключевыми показателя за выбранный отчётный период:

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

Диаграмма воронки продаж позволяет оценить качество привлекаемых лидов:

Диаграмма снакоплением показывает объёмы продаж идостигнутый результат:

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

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

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

Отчёт потелефонным звонкам

Дашборд предназначен для руководителя колл-центра.

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

Диаграмма позвонкам показывает общую картину работы колл-центра иинтенсивность звонков заотчётный период:

Отдельно представлена информация понепринятым ипотерянным (когда менеджер неперезвонил клиенту) звонкам.

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

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

График подлительности звонков позволяет проанализировать работу менеджеров:

  • насколько оперативно отвечают;

  • как долго разговаривают склиентом;

  • почему пропускают входящие звонки.

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

Digital

Дашборд предназначен для менеджеров порекламе.

Надашборде представлена динамика стандартных метрик интернет-рекламы заотчётный период. Панель фильтров позволяет более детально проанализировать каждый канал.

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

Сделки

Дашборд для отдела продаж ибухгалтерии.

Панель карточек вверху показывает сводную информацию позаключенным сделкам:

Диаграмма посуммам сделок показывает реальные ипотенциально возможные суммы позаключенным договорам:

Диаграмма потипам оплат позволяет выявить предпочтения клиентов иоценить объёмы длинных денег (рассрочка/ипотека):

Внизу таблица сдетальной информацией попроданным объектам:

Вней можно выявить предпочтения клиентов повидам оплат, объекту продаж, метражу идругим показателям.

Как дашборд помогает застройщику

Отчёт застройщика вPower BIпредоставляет существенные преимущества для анализа продаж:

  1. Информация изразных источников собрана водном отчёте.

  2. Гибкая система фильтров позволяет индивидуально выбирать отчётный период, детализировать информацию понеобходимым параметрам.

  3. Засчёт ежедневного обновления данных вотчёте можно получать актуальную информацию.

  4. Можно своевременно выявлять критические ситуации, неэффективные рекламные каналы ит.д. иоперативно реагировать наситуацию.

  5. Вместо громоздких таблиц наглядные диаграммы играфики. Они позволяют проще воспринимать иинтерпретировать информацию.

  6. Можно сократить цикл сделки засчёт повышения качества лидов, эффективности рекламы, оптимизации работы менеджеров, своевременного выявления проблемных мест.


Подробнее..

Первые шаги в BI-аналитике. Роль Data Engineering

01.05.2021 10:11:55 | Автор: admin

Добрый день, уважаемые читатели! Материал носит теоретический характер и адресован исключительно начинающим аналитикам, которые впервые столкнулись с BI-аналитикой.

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

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

В таком случае происходит следующее: сбор, обработка и анализ данных происходит силами единственного инструмента самой BI-платформой. При этом данные предварительно никак не очищаются, не проходят компоновки. Забор информации идет из первичных источников без участия промежуточного хранилища. Результаты такого подхода можно легко лицезреть на тематических форумах. Если постараться обобщить все вопросы касательно BI-инструментов, то в топ-3 попадут, наверное, следующие: как загрузить в систему плохо структурированные данные, как по ним рассчитать требуемые метрики, что делать, если отчет работает очень медленно. Что удивительно, на этих форумах вы практически не найдете обсуждений ETL-инструментов, описания опыта применения хранилищ данных, лучших практик программирования и запросов SQL. Более того, я неоднократно сталкивался с тем, что опытные BI-аналитики не очень лестно отзывались о применении R/Python/Scala, мотивируя это тем, что все проблемы можно решить только силами BI-платформы. Вместе с тем всем понятно, что грамотный дата инжиниринг позволяет закрывать массу проблем при построении BI-отчетности.

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

Data BI Самый простой вариант. Именно с него начинается прототипирование управленческих панелей. В роли источника данных часто выступает отдельный (-ые) статичный файл (csv, txt, xlsx и т. д.).

Плюсы. Самый быстрый способ построения отчетности. Идеально подходит, для ситуационной аналитики или когда результат нужен был еще вчера. Не требует применения вспомогательных инструментов, следовательно, не нужно тратить ресурсы на их поддержание. Аналитик BI не обязан иметь компетенции в области дата инжиниринга или программирования.

Минусы. Далеко не изо всех источников можно забрать информацию напрямую (пример, прикладные решения на платформе 1С). Если массивы плохо структурированы, то это потребует много дополнительных шагов по их обработке. Качество данных никак не проверяется (проблема дубликатов, пустых строк, некорректного написания значений и т. д.). При большом количестве строк заметно замедляется работа самой BI-платформы, вплоть до полной невозможности перестраивать графики и диаграммы. Нет возможности составить расписание на обновление исходников.

Data DB BI Вариант похож на предыдущий за тем исключением, что первоначальный массив напрямую заливается в базу в неизмененным виде, а уже к ней идет подключение. База данных может быть как развернута локальна, запущена в контейнере, так и представлена облачным хранилищем.

Плюсы. Есть возможность агрегировать разрозненные, однотипные файлы. Нагрузку по хранению информации теперь несет хранилище. Есть возможность задействовать всю мощь языка запросов SQL (или его диалекта), чтобы отфильтровать или агрегировать сырые строки перед их передачей в BI-инструмент. Уменьшается размер файла с управленческими панелями.

Минусы. Нет контроля над первичными данными, поэтому в хранилище заливается большое количество ненужной информации. Качество загружаемых датасетов никак не контролируется. Добавление данных в базу осуществляется в ручном режиме. Аналитик должен на базовом уровне знать SQL.

Data ETL DB BI Частичная автоматизация. В качестве ETL-инструмента может выступать как программный продукт с графическим интерфейсом, так и код написанный на R/Python/Scala и т. д. Все данные проходят предварительный предпроцессинг. Структура наполняемых таблиц прописывается заранее.

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

Минусы. Аналитик должен уверенно владеть ETL-инструментом и языком запросов SQL. Процесс разработки и тестирования скриптов требует времени. Если источников информации много, то затрудняется синхронизация получения информации.

Для иллюстрации этого варианта я решил написать простейшие скрипты. В рамках игрушечного примера я использую SQLite. Это позволит прикрепить базу данных к публикации, чтобы каждый желающий мог попрактиковаться в написании скриптов (архив). Датасет для разбора это E-Commerce Data с сайта Kaggle.

# импорт библиотекimport pandas as pd# опции отображенияpd.set_option('display.max_columns', 10)pd.set_option('display.expand_frame_repr', False)path_dataset = 'dataset/ecommerce_data.csv'# Предварительная обработка датасетаdef func_main(path_dataset: str):    # Считываем датасет    df = pd.read_csv(path_dataset, sep=',')    # Приводим названия столбцов датасета к нижнему регистру    list_col = list(map(str.lower, df.columns))    df.columns = list_col    # Избавляемся от времени и трансформируем строку-дату в правильный формат    df['invoicedate'] = df['invoicedate'].apply(lambda x: x.split(' ')[0])    df['invoicedate'] = pd.to_datetime(df['invoicedate'], format='%m/%d/%Y')    # Рассчитываем сумму покупки по каждому товару    df['amount'] = df['quantity'] * df['unitprice']    # Удаляем ненужные для дальнейшего анализа столбцы    df_result = df.drop(['invoiceno', 'quantity', 'unitprice', 'customerid'], axis=1)    # Задаем порядок вывода столбцов для визуального контроля результата    df_result = df_result[['invoicedate', 'country', 'stockcode', 'description', 'amount']]    return df_result# Таблица Продажиdef func_sale():    tbl = func_main(path_dataset)    df_sale = tbl.groupby(['invoicedate', 'country', 'stockcode'])['amount'].sum().reset_index()    return df_sale# Таблица Страныdef func_country():    tbl = func_main(path_dataset)    df_country = pd.DataFrame(sorted(pd.unique(tbl['country'])), columns=['country'])    return df_country# Таблица Товарыdef func_product():    tbl = func_main(path_dataset)    df_product = tbl[['stockcode','description']].\        drop_duplicates(subset=['stockcode'], keep='first').reset_index(drop=True)    return df_product

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

# импорт библиотекimport pandas as pdimport sqlite3 as sqfrom etl1 import func_country,func_product,func_salecon = sq.connect('sale.db')cur = con.cursor()## Таблица Страны# cur.executescript('''DROP TABLE IF EXISTS country;#                     CREATE TABLE IF NOT EXISTS country (#                     country_id INTEGER PRIMARY KEY AUTOINCREMENT,#                     country TEXT NOT NULL UNIQUE);''')# func_country().to_sql('country',con,index=False,if_exists='append')## Таблица Товары# cur.executescript('''DROP TABLE IF EXISTS product;#                     CREATE TABLE IF NOT EXISTS product (#                     product_id INTEGER PRIMARY KEY AUTOINCREMENT,#                     stockcode TEXT NOT NULL UNIQUE,#                     description TEXT);''')# func_product().to_sql('product',con,index=False,if_exists='append')## Таблица Продажи (основная)# cur.executescript('''DROP TABLE IF EXISTS sale;#                     CREATE TABLE IF NOT EXISTS sale (#                     sale_id INTEGER PRIMARY KEY AUTOINCREMENT,#                     invoicedate TEXT NOT NULL,#                     country_id INTEGER NOT NULL,#                     product_id INTEGER NOT NULL,#                     amount REAL NOT NULL,#                     FOREIGN KEY(country_id)  REFERENCES country(country_id),#                     FOREIGN KEY(product_id)  REFERENCES product(product_id));''')## Таблица Продажи (временная)# cur.executescript('''DROP TABLE IF EXISTS sale_data_lake;#                     CREATE TABLE IF NOT EXISTS sale_data_lake (#                     sale_id INTEGER PRIMARY KEY AUTOINCREMENT,#                     invoicedate TEXT NOT NULL,#                     country TEXT NOT NULL,#                     stockcode TEXT NOT NULL,#                     amount REAL NOT NULL);''')# func_sale().to_sql('sale_data_lake',con,index=False,if_exists='append')## Перегружаем данные из вспомогательной таблицы (sale_data_lake) в основную (sale)# cur.executescript('''INSERT INTO sale (invoicedate, country_id, product_id, amount)#                     SELECT  sdl.invoicedate, c.country_id, pr.product_id, sdl.amount#                     FROM sale_data_lake as sdl LEFT JOIN country as c ON sdl.country = c.country#                     LEFT JOIN product as pr ON sdl.stockcode = pr.stockcode#                     ''')## Очищаем вспомогательную таблицу# cur.executescript('''DELETE FROM sale_data_lake''')def select(sql):  return pd.read_sql(sql,con)sql = '''select *        from (select s.invoicedate,                      c.country,                      pr.description,                      round(s.amount,1) as amount               from sale as s left join country as c on s.country_id = c.country_id                            left join product as pr on s.product_id = pr.product_id)'''print(select(sql))cur.close()con.close()

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

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

Так как BI-инструмент не может из коробки напрямую подключиться к SQLite напишем простейший скрипт на Python.

import pandas as pdimport sqlite3 as sqcon = sq.connect('C:/Users/Pavel/PycharmProjects/test/sale.db')cur = con.cursor()def select(sql):  return pd.read_sql(sql,con)sql = '''select *        from (select s.invoicedate,                      c.country,                      pr.description,                      replace(round(s.amount,1),'.',',') as amount               from sale as s left join country as c on s.country_id = c.country_id                            left join product as pr on s.product_id = pr.product_id)'''tbl = select(sql)print(tbl)

После загрузки данных в систему и проверки корректности распознанных форматов можно приступать к непосредственному построению дашборда.

Data Workflow management platform + ETL DB BI Полная автоматизация. Оркестратор скриптов берет на себя контроль за своевременным выполнением всех вспомогательных процессов в системе.

Плюсы. Возможность оптимально настроить время сбора данных из разрозненных источников. Можно мониторить ошибки и перезапускать упавшие задачи.

Минусы. Усложнение инфраструктуры. Рост требований к квалификации аналитика BI. Необходимо осваивать дополнительные инструменты или языки программирования.

Data Workflow management platform + ELT Data Lake Workflow management platform + ETL DB BI Самый сложный вариант, где информация проходит двухступенчатый конвейер: сначала это неструктурированные данные (Data Lake), а затем уже хранилище (DB), где информация отсортирована и преобразована к требуемому виду.

Плюсы. Возможность разнести во времени сбор информации и ее обработку. Если на этапе проектирования таблиц учтены не все требования, возможно обращение за дополнительными данными в Data Lake.

Минусы. Аналогичны предыдущему варианту. Если выбранная платформа Data Lake платная, как следствие рост расходов на аналитику компании.

Краткие выводы.

  • Построение BI-аналитики без даты инжиниринга возможно лишь на старте.

  • Если аналитик BI работает в единственном числе и система постоянно усложняется, то он обязан подменять собой сразу несколько специалистов.

  • Понимание базовых принципов построения хранилищ данных, уверенное владение SQL, программирование на каком-либо языке и, конечно, дизайнерские навыки вот далеко не полный перечень требований к сотруднику, которому делегируется проектировать управленческие панели.

На этом все. Всем здоровья, удачи и профессиональных успехов!

Подробнее..

Из песочницы Как выбрать инструмент для бизнес-анализа

08.10.2020 18:22:32 | Автор: admin

Какой у Вас выбор?


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

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

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

Приведенные особенности BI-систем заставляют задуматься о подборе альтернативы. Далее я предлагаю сравнить решение стандартного набора задач при подготовке отчетности с помощью Power BI и Excel.

Power BI или Excel?


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

А как решается эта задача с помощью Power BI?

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

Какие преимущества применения Power BI по сравнению с традиционным подходом можно заметить в приведенном примере?

1 Автоматизация процедуры получения данных и подготовка их к анализу.
2 Построение бизнес-модели.
3 Невероятная визуализация.
4 Разграниченный доступ к отчетам.

А теперь давайте разберем каждый пункт по отдельности.

1 Для подготовки данных к построению отчета, нужно единожды определить процедуру, выполняющую подключение к данным и их обработку и каждый раз, когда понадобится получить отчет за другой период, Power BI будет пропускать данные через созданную процедуру. Таким образом автоматизируется большая часть работы по подготовки данных к анализу. Но дело в том, что Power BI осуществляет процедуру подготовки данных с помощью инструмента, который доступен в классической версии Excel, и называется он Power Query. Он позволяет выполнить поставленную задачу в Excel абсолютно тем же способом.

2 Здесь та же ситуация. Инструмент Power BI для построения бизнес-модели имеется и в Excel это Power Pivot.

3 Как Вы, наверное, уже догадались, с визуализацией дело обстоит подобным образом: расширение Excel Power View справляется с этой задачей на ура.

4 Остается разобраться с доступом к отчетам. Тут не так все радужно. Дело в том, что Power BI это облачный сервис, доступ к которому осуществляется через персональную учетную запись. Администратор сервиса распределяет пользователей по группам и задает для этих групп различный уровень доступа к отчетам. Этим достигается разграничение прав доступа между сотрудниками компании. Таким образом, аналитики, менеджеры и директора заходя на одну и туже страницу видят отчет в доступном для них представлении. Может быть ограничен доступ к определенному набору данных, либо к отчету целиком. Однако, если отчет находится в файле формата Excel, то усилиями системного администратора можно попытаться решить задачу с доступом, но это будет уже не то. Я еще вернусь к рассмотрению этой задачи, когда буду описывать особенности корпоративного портала.

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

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

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

ETL и DWH


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

С их помощью осуществляется выгрузка данных из источников (Extract), их преобразование (Transform), что подразумевает очистку и сопоставление, и загрузка в хранилище данных (Load). Хранилище данных (DWH Data Warehouse) это, как правило, реляционная база данных, расположенная на сервере. Эта база содержит данные, пригодные для анализа. По расписанию запускается ETL-процесс, который обновляет данные хранилища до актуальных. Кстати говоря, всю эту кухню прекрасно обслуживает Integration Services, входящие в состав MS SQL Server.

Далее, как и раньше для построения бизнес-модели данных и визуализации можно воспользоваться Excel, Power BI, либо другими аналитическими инструментами, такими как Tableau или Qlik Sense. Но прежде, мне бы хотелось обратить Ваше внимание еще на одну возможность, о которой Вы могли не знать, несмотря на то, что она Вам давно доступна. Речь идет о построении бизнес-моделей с помощью аналитических служб MS SQL Server, а именно Analysis Services.

Модели данных в MS Analysis Services


Этот раздел статьи будет более интересен тем, кто уже использует MS SQL Server в своей компании.

На данный момент службы Analysis Services предоставляют два вида моделей данных это многомерная и табличная модели. Кроме того, что данные в этих моделях связаны, значения показателей модели предварительно агрегируются и хранятся в ячейках OLAP кубов, доступ к которым осуществляется MDX, либо DAX запросами. За счет такой архитектуры хранения данных, запрос, который охватывает миллионы записей, возвращается за секунды. Такой способ доступа к данным необходим компаниям, таблицы транзакций которых содержат от миллиона записей (верхний придел не ограничен).

Excel, Power BI и многие другие солидные инструменты умеют подключаться к таким моделям и визуализировать данные их структур.

Если Вы пошли продвинутым путем: автоматизировали процесс ETL и построили бизнес-модели при помощи служб MS SQL Server, то Вы достойны иметь свой собственный корпоративный портал.

Корпоративный портал


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

Однако, пока не понятно, как будет организовано отображение отчетов на странице портала. Чтобы ответить на этот вопрос, сначала нужно определиться с технологией, на основе которой будет строиться портал. Я предлагаю взять за основу один из фреймворков: ASP.NET MVC/Web Forms/Core, либо Microsoft SharePoint. Если в Вашей компании имеется хотя бы один .NET разработчик, то выбор не составит труда. Теперь можно подбирать встраиваемый в приложение OLAP-клиент, способный подключаться к многомерным или табличным моделям служб Analysis Services.

Выбор OLAP-клиента для визуализации


Сравним несколько инструментов по уровню сложности встраивания, функциональности и цене: Power BI, компоненты Telerik UI for ASP.NET MVC и компоненты RadarCube ASP.NET MVC.

Power BI


Чтобы организовать доступ сотрудников компании к отчетам Power BI на странице своего портала, нужно воспользоваться функцией Power BI Embedded.

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

Сначала отчет, сформированный в Power BI Desktop, публикуется на портале Power BI и потом, с помощью не простой настройки, встраивается в страницу web-приложения.

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

Компоненты Telerik и RadarCube


Для встраивания компонентов Telerik и RadarCube достаточно владеть программными технологиями на базовом уровне. Поэтому профессиональных навыков одного программиста из IT-отдела будет вполне достаточно. Все что нужно, это разместить компонент на web-странице и настроить их под свои нужды.

Компонент PivotGrid из набора Telerik UI for ASP.NET MVC встраивается на страницу в изящной манере Razor и предоставляет самые необходимые OLAP-функции. Однако, если требуется более гибкие настройки интерфейса и развитый функционал, то лучше использовать компоненты RadarCube ASP.NET MVC. Большое количество настроек, богатый функционал с возможностями его переопределения и расширения, позволят создать OLAP-отчет любой сложности.

Ниже приведу таблицу сравнения характеристик рассматриваемых инструментов по шкале Низкий-Средний-Высокий.

Power BI Telerik UI for ASP.NET MVC RadarCube ASP.NET MVC
Визуализация Высокий Низкий Средний
Набор OLAP-функций Высокий Низкий Высокий
Гибкость настройки Высокий Высокий Высокий
Возможность переопределения функций - - +
Программная кастомизация - - +
Уровень сложности встраивания и настройки Высокий Низкий Средний
Минимальная стоимость Power BI Premium EM3

190 000 руб./месяц
Лицензия на одного разработчика

90 000 руб.

Лицензия на одного разработчика

25 000 руб.


Теперь можно перейти к определению критериев для выбор аналитического инструмента.

Условия выбора Power BI


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

Условия выбора компонентов Telerik


  • Нужен простой OLAP-клиент для Ad hock анализа.
  • В штате компании имеется .NET разработчик начального уровня.
  • Небольшой бюджет на разовую покупку лицензии и дальнейшее ее продление со скидкой менее 20%.

Условия выбора компонентов RadarCube


  • Необходим многофункциональный OLAP-клиент с возможностью кастомизации интерфейса, а также поддерживающий встраивание собственных функций.
  • В штате компании имеется .NET разработчик среднего уровня. Если такого нет, то разработчики компонента любезно предоставят свои услуги, но за дополнительную плату, не превышающую уровня оплаты труда штатного программиста.
  • Небольшой бюджет на разовую покупку лицензии и дальнейшее ее продление со скидкой 60%.

Заключение


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

Разработка бизнес-приложений 2 бесплатных тренинга на русском в декабре

07.12.2020 10:20:40 | Автор: admin
Привет, Хабр! В этой статье рассказываем о двух крутых мероприятиях для бизнеса по созданию и управлению бизнес-приложениями. Мероприятия познакомят своих участников с основами двух наших продуктов: Power Platform и Dynamics 365.

Под катом читайте подробности и регистрируйтесь. Ждем вас!



1. Microsoft Power Platform Virtual Training Day: основы


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

Во время этого учебного мероприятия вы:

  • Подготовитесь к сертификационному экзамену по основам Microsoft Power Platform
  • Научитесь создавать инновационные бизнес-решения и управлять ими с помощью Power Platform
  • Легко подключать все свои данные для анализа эффективности бизнеса с помощью специализированных приложений
  • Автоматизировать рабочие процессы для улучшения повседневных процессов независимо от ваших технических знаний

После прохождения этого бесплатного обучения вы сможете бесплатно сдать сертификационный экзамен по основам Microsoft Power Platform.

Когда: 9 декабря
Язык: английский с субтитрами на русском

Регистрация




Вот чего можно ожидать:

  • Введение
  • Введение в Microsoft Power Platform
  • Введение в Microsoft Power Apps и Common Data Services
  • Перерыв: 10 минут
  • Создавайте простые Power Apps
  • Используйте Microsoft Power Automate
  • Перерыв: 10 минут
  • Используйте Microsoft Power BI
  • Закрытие

2. Microsoft Dynamics 365 Virtual Training Day: основы


Получите навыки, необходимые для того, чтобы помочь вашей организации продавать, обслуживать и оправдывать ожидания клиентов на Microsoft Dynamics 365 Virtual Training Day: Fundamentals. Во время этого бесплатного мероприятия, состоящего из двух частей, вы узнаете, как Dynamics 365 может помочь повысить эффективность, которая стимулирует инновации и поддерживает индивидуальный подход как для сотрудников, так и для клиентов.

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

Во время этого учебного мероприятия вы узнаете, как:

  • Подготовиться к сертификационному экзамену по основам Microsoft Dynamics 365.
  • Создать единую комплексную платформу для своего бизнеса, которая работает так же удаленно, как и в офисе.
  • Использовать приложения на основе моделей, чтобы повысить эффективность масштабирования.
  • Поддерживать индивидуальный подход как для сотрудников, так и для клиентов.

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

Когда: 16-17 декабря
Язык: английский с субтитрами на русском

Регистрация




Вот чего можно ожидать:
Введение Введение
Введение в Microsoft Dynamics 365 Финансы и управление цепочками поставок
Dynamics 365: приложения на основе моделей (продажи, маркетинг) перерыв: 10 минут
перерыв: 10 минут Приложения для финансов и operations (коммерция, HR)
Dynamics 365: приложения на основе моделей (Обслуживание клиентов) Безопасность Dynamics 365
перерыв: 10 минут перерыв: 10 минут
Анализ данных Dynamics 365 Интеграция Dynamics 365
Завершение Завершение
Подробнее..

Из песочницы Работа с enterprise как мы не сделали систему аналитики для SaaS сервиса

08.08.2020 16:12:48 | Автор: admin
Мы сильно обрадовались новому контракту и уже представляли, как логотип клиента приукрасит наше портфолио. Но все оказалось не так радужно. Расскажем, как мы работали с дочкой крупной российской IT-компании, и почему у нас не получилось сделать крутой проект.



О проекте


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

Структура процессов


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

  1. Менеджеры отвлекались на ненужные этапы воронки продаж, и их работа никак не контролировалась;
  2. Отчеты по продажам ежедневно выгружались из админки вручную;
  3. Было мало конверсионных событий для сбора аналитики.

Далее сделали карту со структурой взаимодействия всех систем. В ней показано, по какой логике должны идти события, и на каких этапах собирается аналитика. Основные данные берем из CRM и соотносим их с данными по рекламе и конверсиям. Собираем в myBI, визуализируем в Power BI.

Воронки продаж


Продажи у клиента велись в Enybox CRM, их мы перенесли в amoCRM для удобства интеграции. Логику продаж получилось собрать в три воронки.


Три последовательные воронки

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

Как должна была работать аналитика


Изначальные события Итоговые события
Форма обратной связи Форма обратной связи
Регистрация в сервисе Регистрация в сервисе
Первое пополнение
Тестирование (опционально при небольшом пополнении)
Повторные пополнения
Отказ от использования (прогрев через ОП)

Для нормальной работы системы аналитики нужно собирать все события = отмечать конверсионные действия. События уже попадали в систему аналитики, но изначально их было только два типа, что недостаточно для отчетов.

Отображение данных


Пример дашборда

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

В момент конверсии на сайте генерировался отдельный ID для синхронизации рекламных систем и CRM. По этому ID мы связывали данные расходов и доходов. Так мы соотносили данные и могли строить по ним отчеты.

Юнит экономика. Retention



График rolling-retention'а сервиса с 1 по 12 месяц

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

Конверсия в первое пополнение



Конверсия сильно зависела от количества новых клиентов и начала их оплат. Первые 9 месяцев мы получали примерно по 430 новых регистраций и по 90 оплат от новых пользователей ежемесячно. Конверсия в покупку в месяц регистрации составила 20%, по данным за 12 месяцев.

Помимо стандартных показателей


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

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

Что пошло не так


В самом начале инициаторы проекта отложили старт до осени (обратились весной). Такие пробелы в работе происходили не раз. Но мы не задумывались об этом и принимали как должное. Главными проблемами были коммуникация и бюрократия в процессах нашего клиента. Так можно изобразить весь временной отрезок работы над проектом:



Медленная разработка


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

Все менеджеры и разработчики на их стороне работали по двухнедельным итерациям. Но они постоянно ставили наш проект последним по приоритету и часто наши задачи не попадали в спринт.

Плохая коммуникация и отсутствие экспертизы


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

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

Представьте себе воронку продажи, как на рисунке выше. В одном из этапов менеджерам нужно узнать как дела у клиента. Как думаете, что произойдет с аналитикой конверсий такой воронки?

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


Факапы с нашей стороны


Мы не учли пропускную способность системы. На одно событие платформы в пике мы передавали до 10 запросов к amoCRM, чтобы выполнить логику бизнес-процессов.

100 000 ивентов в сутки * 10 запросов к amoCRM = 1 000 000 запросов в сутки

1 000 000 запросов в сутки / 10 запросов в секунду (ограничение амо) = 100 000 секунд = 27 часов

Итог: синхронизация никогда не закончится

Изначально выбрали amoCRM, так как проходи по лимиту запросов к системе. Но с течением развития проекта требования и функции увеличились и мы уперлись в лимит.
Мы выбрали неподходящий инструмент. AmoCRM физически не подходит для обработки большого количества запросов.
Также ошибка была в том, что мы разрабатывали все на GO, и за это отвечал один специалист. Когда он ушел, осталась гора legacy кода, который никто не смог бы разобрать. Но, к сожалению, или к счастью это не было нужно.

Опять все сломали


Этот кейс еще один пример проекта, который закопали в согласованиях и куче неоправданного менеджмента.

Нам не хватило экспертности в техническом плане. Клиенту устойчивости в управлении и желания довести проект до конца.

Но это опыт. Благодаря ему теперь подобные задачи выглядят максимально тривиально и мы уже воспроизвели подобное решение в рамках другого проекта.

Как можно было избежать неудачи


Чтобы не повторять таких кейсов в будущем, мы выделили аспекты, которые нужно соблюдать в работе с enterprise клиентами.

  1. Держать контакт с менеджером проекта: понимать его мотивацию; помогать ему защищать презентации перед руководителями. Делать все, чтобы стейкхолдер не потерял интерес к проекту.
  2. Соблюдать структуру коммуникации. Все важные чекпоинты проекта фиксировать по почте. Все обсуждения на встречах собирать в краткое резюме. Так специалистам со стороны клиента будет проще находиться в контексте действий. Не нужно будет каждый раз восстанавливать цепочку событий.
  3. Определять мотивацию специалистов со стороны клиента при старте работ. Если проект не стоит в их KPI и он изначально в низком приоритете завершить его будет практически невозможно.
  4. Думать наперед. Даже при разработке MVP нужно смотреть, на узкие места, которые могут возникнуть в будущем. Проект всегда расширяется и важно предусмотреть структуру, чтобы не переписывать весь код с нуля.



Автор статьи Фёдор Анисимов, маркетолог LAND PRO.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru