Веские аргументы. К вопросу аналитики в компании / Блог компании ООО «ИЛАДА» / Хабр

Веские аргументы. К вопросу аналитики в компании / Блог компании ООО «ИЛАДА» / Хабр Аналитика

Почему штатный аналитик, а не агентство или фрилансер?

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

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

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

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

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

И тут возникает первый и, пожалуй, самый сложный вопрос… Как найти такого специалиста?

Это самая главная и вместе с тем трудная задача для интернет-маркетолога — найти хорошего аналитика. Уточню: речь не просто о человеке, который умеет хорошо считать. Я говорю о специалисте, который вникает и понимает, как формируется цифра, а значит, должен быть очень гибким и коммуникабельным. Необходимо работать с большим объемом данных, и в основном с сырыми данными, поэтому надо знать «природу» цифры.

Помимо этого, необходимо разбираться в BI системах: чем отличается коробочная (локальная) система от онлайн-системы, какие риски присутствуют при использовании каждой из них и что нужно, чтобы начать работать здесь и сейчас. Уметь работать с такими расширениями, как xml, json, csv (с различными разделителями: «,», «;», знать, чем они отличаются и что лучше использовать) и т.д.

Допустим, вы определились с таким специалистом. С чего начать его работу в компании?

Сервис сквозной аналитики. что выбрать?

Пару слов о сервисе сквозной аналитики. Я в свое время пробовал выстраивать систему сквозной аналитики на основе Google Analytics (отправляя туда все данные, которые только мог). После обновления их системы я понял, что получил знания «как не нужно делать» и «как потратить время зря», создавая проект на неконтролируемой системе. То же самое меня ждало с Яндекс.Метрикой…

Другая плохая идея — собственная система. Почему сразу плохая? Если у вас не кружок энтузиастов, состоящий из 1–2 аналитиков и как минимум из 3–5 программистов, то это игра вдолгую, без возможности корректного применения на практике. Один специалист всегда упрется в потолок проверки написанной им системы и оценки качества полученных вычислений.

Третья плохая идея — открыть поисковую систему, вбить «топ-5 систем сквозной аналитики», открыть первые пару ссылок, бегло прочитать описание, найти интересующий тариф и начать внедрение сквозной аналитики.

Так как же быть, какой сервис выбрать? Все просто. На этот вопрос уже давно дан ответ: идете в магазин или интернет-магазин, покупаете PMBoK (Project Management Body Of Knowledge — свод знаний по управлению проектами) и получаете фактически практическое руководство на ближайшие N 1 лет.

При этом важно:

  1. Понять, что система сквозной аналитики — это не задача, а проект.
  2. Определиться с сутью проекта: это разработка или внедрение? Если выбираете разработку, сами для себя распишите бюджеты, MVP и сроки.
  3. Ответить на вопрос: каковы риски проекта?
  4. Определиться с заинтересованными лицами и ресурсами проекта:
    1. Кто ключевые пользователи.
    2. Кто куратор проекта.
    3. Что представляет собой команда проекта.
    4. Какая будет использована инфраструктура т.е. оборудование, программное обеспечение, лицензии.

Если аналитик в данном контексте — ключевая фигура команды проекта, то сервис сквозной аналитики — «сердце» инфраструктуры.

Что выбрал я, выстраивая систему сквозной аналитики в «К 31»?

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

Почему мы выбрали именно эту систему?

  1. Вы и так платите за систему аналитики, дополнительных больших финансовых вложений не потребуется.
  2. В CoMagic есть разнообразные отчеты: «Воронка продаж», DashBoard, «Сделки». Они подключаются за небольшую плату, не требуется заключать отдельные договора, просто позвоните своему менеджеру или включите их в личном кабинете и начните работать.
  3. Документация по API. Вы сможете без особого труда понять, как получать и передавать данные между системами, не будучи высокоуровневым программистом.
  4. Нативные интеграции с различными CRM и аналитическими системами: можно настроить работу в один клик.

Таким образом, использование CoMagic* на первом этапе построения системы сквозной аналитики для нас стало отличным решением. Мы смогли оценить трудозатраты, проверить наши возможности, а также увидеть подводные камни.

Не дайте ему уйти!

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

При правильном подходе сотрудник на должности аналитика может работать от 3 лет. Что для этого нужно?

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

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

  1. Давать возможность раз в год за счет компании (полностью или частично) посещать курсы. Законный вопрос: «Зачем? Ему надо, пусть сам и учится». Во-первых, вы увидите, вовлечен в данную сферу специалист или уже начинает перегорать и скоро покинет проект. Во-вторых, специалистов, которые действительно хотят расти, мотивируют фирмы, которые дают не только возможности, но и способы. Они могут привносить новое дыхание, виденье.

Благодаря своей компании я не только посетил платные курсы, но и постоянно ездил на различные мероприятия (RIW, Mail, Яндекс, мероприятия, посвященные ИТ в здравоохранении, ИИ в медицине). После таких мероприятий у нас горели глаза, мы видели наших конкурентов, которые уже сделали, а мы еще не начинали, и все это нас очень мотивировало.

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

4 вида аналитики данных для эффективного управления на практическом iiot-примере

Начнем с практического определения: аналитика данных – это процесс поиска системных закономерностей в массивах информации и интерпретации найденных фактов с целью получения важных для бизнеса сведений (инсайтов, insights), которые позволят оптимизировать деятельность: увеличить доход, сократить затраты или достичь других важных результатов [1].

Принято выделять 4 вида аналитики данных, отличающихся уровнем сложности работы с информацией и степенью человеческого участия [2]:

  • Описательная (дескриптивная), которая отвечает на вопрос «Что случилось?», создавая сводку исторических данных для их дальнейшего анализа. Например, непрерывный сбор информации с производственного оборудования с помощью smart-датчиков и других IoT/IIoT-устройств позволит точно идентифицировать момент сбоя в технологическом процессе.
  • Диагностическая, которая анализирует информацию, чтобы ответить на вопрос «Почему это случилось?». Здесь используются статистические методы анализа данных с целью их кластеризации, классификации, детализации и обнаружения корреляции, чтобы выявить основные факторы влияния на результаты. В рассмотренном выше примере с промышленным интернетом вещей (Industrial Internet of Things, IIoT) диагностическая аналитика покажет, что авария случилась по причине выхода из строя модуля приемки сырья.
  • Предиктивная (прогнозная, предсказательная), которая прогнозирует неизвестные события в будущем, отвечая на вопрос «Что может случиться?» на основе анализа накопленной информации. Здесь используется множество методов: математическая статистика, моделирование, машинное обучение и другие области Data Science, а также интеллектуальный анализ данных (Data Mining). К примеру, предиктивная аналитика текущих и прошлых показателей работы производственного оборудования заблаговременно определит время его профилактического ремонта, чтобы избежать поломки дорогостоящей техники. Как это работает на практике в нефтегазовой отрасли, мы рассказывали в этой статье.
  • Предписывающая (предписательная), которая отвечает на, пожалуй, главный управленческий вопрос «Что делать?». Здесь машинное обучение и другие методы искусственного интеллекта анализируют все накопленные и обработанные данные, чтобы найти наилучшие решения для конкретной ситуации. В рассматриваемом примере модуль предписывающей аналитики подскажет, какая именно деталь производственного оборудования больше всего износилась и как это исправить наиболее оптимальным с точки зрения экономики образом: заменить на новую или отремонтировать.
предиктивная аналитика, описательная аналитика, диагностическая аналитика, предписывающая аналитика
Аналитическая пирамида: от описательной к предписывающей аналитики данных

Ruli24: детали решают

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

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

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

Психологи утверждают, что порядок на рабочем столе – это не только удобное расположение вещей. Это еще и визитная карточка каждого сотрудника: отражение порядка в его голове, в мыслях, делах. С Рули24 просто соблюдать порядок на «рабочем столе» компьютера, а значит, удобно собирать данные по своему виду деятельности.

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

Дополнительный анализ:  Как в 1С:Бухгалтерии 8 проанализировать данные по контрагентам в разрезе договоров с помощью отчета Анализ субконто? Первый Бит

мы разработали специальный механизм, который позволяет отсечь 90% неиспользуемой информации. Любой сотрудник может самостоятельно настроить свое «Избранное» и работать только с теми документами и аналитическими отчётами, которые ему нужны. Все будет предварительно отсортировано, отфильтровано, детализировано и сгруппировано по заданным параметрам и меткам.

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

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

Количество папок и документов на рабочем столе формирует сам пользователь: «Запросы», «Задания», «Файлы» и прочее. Кстати, к любому запросу можно приложить файл. Что тоже удобно: пользователю не нужно будет заниматься описками необходимого документа.

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

На рабочем столе также можно разместить и часто используемые операции. Например, в папке «Отправить в банк» будут содержаться документы и выписки, которые необходимо доставить в банк. Плюс в том, что система четко будет отражать — отправлен документ или выписка в кредитное учреждение или все еще находится в офисе.

Еще один плюс Рули24 — возможность детализации информации. Любые данные можно уточнять под конкретный запрос. Например, по конкретному клиенту выводится информация о наличии договоров, спецификация, график платежей, график поставок, акты, накладные и так далее.

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

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

Представьте, что на рабочем столе находятся Excel таблицы. Если на иконке в левом углу есть значок « », то при нажатии на него вы сразу входите на страницу ввода данных в эту таблицу. Если такого значка нет, то вы открываете таблицу для просмотра. Далее нужно освоить работу с этой таблицей.

Работа с остальными таблицами будет аналогичной. Нужно запомнить всего пять типов действий с данными в таблице: правка, состояние, операции, сервис, вид. «Правка» обеспечивает ввод, корректировку, удаление и печать данных таблицы. «Состояние» обеспечивает возможность изменения статуса документа (внимание, открыто, выполнено и пр).

«Операции» — специфичны для каждого документа. «Сервис» — очень полезные функции, которые отсутствуют в большинстве систем: фильтр, группировка, информация по колонке, избранное. «Вид» — представление на экране: таблица, дерево, аналитика, настройка, детализация. Функции применимы для всех таблиц и представлений.

Несмотря на мощность редакторов, у Ruli24 есть и преимущества перед электронными таблицами. Например, в Excel, выбрав данные, можно построить диаграмму. Но в Рули24 графики можно составить на основе сразу нескольких взаимосвязанных таблиц. В Excel эта функция всё же имеет ограничения.

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

В конце поста стоит сказать о нескольких золотых правилах аналитики, которые мы сформулировали в команде Ruli24 и стремимся использовать как внутри компании, так и при консультировании наших клиентов в процессе внедрения.

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

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

Автоматизируй это!

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

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

Автоматизация при работе с данными обеспечивает быстрый доступ, лёгкую обработку, визуализацию и работу с пулом информации через удобный GUI. Ещё одно преимущество хранения данных в корпоративной информационно системе — сложность компрометации данных: менеджер может ошибиться при фильтрации, нарушить таблицы и даже попытаться всё стереть (поверьте, такое бывает!).

  • Несогласованности и неоднородности данных. Вся отчётность формируется в унифицированных формах, а карточки ввода данных с помощью правил ввода и масок решают проблему формата вносимых данных.
  • Разобщённости данных — внутри корпоративной информационной системы все данные собираются в привязке к сущностям (под капотом это выглядит как связи таблиц в базе данных, но пользователей это обычно не интересует) и поэтому исключаются случаи, когда однородные записи будут храниться в разных таблицах.
  • Недостоверности данных. Поскольку всегда есть управляющее лицо (руководитель, старший менеджер, аналитик), которое с лёгкостью может сравнить данные и увидеть фальсификацию, соблазн внести ложную информацию быстро пропадает, тем более, что взаимосвязи внутри системы, связь с первичной документацией и бухгалтерским учётом обрекают практически любую подтасовку на провал.
  • Сложности организации данных. В корпоративной информационной системе организация данных — забота СУБД, а пользователь получает удобные наполненные таблицы, в которых данные извлекаются и группируются с помощью фильтров и настраиваемых отчётов. Даже, если пользователю Ruli24 недостаёт функционала системы для интерпретации данных или не устраивает библиотека графики, выход есть: можно выгрузить данные в Excel и продолжить обработку тем методами и средствами, которые нужны сотруднику.

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

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

Например, если отслеживать показатели покупки ассортиментных позиций, можно вовремя увидеть падение спроса (или волны падения спроса), изменить ценовую политику или вывести позицию из ассортимента — таким образом компания избежит формирования остатков на складах и затоваривания.

Необходимо считать как относительные, так и абсолютные показатели. Абсолютные показатели (например, сумма выданных потребительских кредитов в банке) помогают оценить объём реализации, продажи, запасы и проч., рассчитать затраты и прибыль.

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

Мы уже неоднократно упомянули корреляцию и факторный анализ. Эти инструменты помогают отслеживать взаимосвязи и устанавливать влияние одних показателей на другие. Их использование помогает создать тот самый комплекс показателей, который отразит влияние одного процесса компании на остальные.

Аналитик в agile

Сегодня в России и странах СНГ набирают популярность гибкие методологии разработки ПО. При рассмотрении возможности перехода на них (и даже в процессе перехода или начального использования), почти неизбежно встает целый ряд вопросов. Один из них состоит в необходимости участия бизнес аналитика в процессе разработки.

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

Проектная документация имеет тенденцию очень быстро устревать— в особенности в сочетании с Agile, где изменения — норма, а не форс-мажор.

В связи с этим в Agile-методологиях всячески советуется минимизировать документацию:

  • ­Избегать write-only-документации, т. е. той, которую заведомо никто не прочитает.
  • ­Писать лаконично, выделяя главное и опуская излишние детали, ибо детали меняются чаще.
  • ­Использовать больше визуальных образов, схем, графических нотаций.

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

  • ­­Тяжело вводить новых людей в курс проекта.
  • ­Велика вероятность утери общей концепции и видения (проекта в целом и его частей).
  • ­Сложно контролировать качество: непонятно, с чем сверять (в особенности это касается полнофункционального регрессионного тестирования, которое полностью автоматизировать очень тяжело).
  • ­Сложно сопровождать и развивать старую функциональность: все уже забыли, почему и зачем именно так сделали.
Дополнительный анализ:  Аналитика веб-форм в «Яндекс Метрике»

Бизнес аналитика

image

  • Устраняйте двусмысленные требования на самых ранних этапах

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

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

Кейс из практики: месяц разработки был потрачен на функционал переноса списка активностей из объекта №1 в объект №2. На этапе приемочного тестирования обнаружилось, что заказчик ожидал совершенно иной функционал — копирование, а не перенос активностей. В процессе переделывания функционала и детализации двусмысленности IT-команда, во-первых, договорилась с заказчиком о MVP, а, во-вторых, о необходимости работы с корнем бизнес-проблемы. Было выдвинуто предположение, что сам функционал копирования требуется только лишь по причине недостаточно качественно реализованного функционала подгрузки шаблонов активностей.

  • Не бойтесь уточнять у заказчика о целях требования

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

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

Записывайте цели вместе с заказчиком, чтобы абсолютно все участники процесса в любой момент времени понимали, зачем они выполняют свою работу.

  • Требуйте у заказчика своего присутствия на бизнес-встречах

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

Во время очной встречи руководителя подразделения с подчиненным, где мы — аналитик и UX-дизайнер — сидели «в фоне», выявился целый ряд требований, который не проявлялся в течение целого года работы команды. Мы обращали внимание на все детали: ручные записи руководителя и сотрудника, на стикеры, на пометки в windows-блокноте, на действия внутри системы. По итогу такой встречи бэклог был существенно дополнен, а мы приступили к глубокой переделке реализованного в системе функционала.

  • Старайтесь достигать соглашения и не формировать отписки

Зачем вообще нужны бизнес аналитики

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

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

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

Более того, обычно, отвечая на «как?», заказчик заводит себя в тупик, потому что не может и не обязан знать, сколько вариантов существует для выполнения его потребности и какой оптимален. Программист же всего лишь делает, что ему сказали. В итоге складывается ситуация, когда недоуменный клиент спрашивает, почему приложение не вписывается в его картину мира, а недоуменный программист отвечает, что так и просили сделать.

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

Кому нужна аналитика?

Команда

знакома с анализом данных не понаслышке. Как мы уже рассказывали, в основе

лежит база данных Oracle. Несмотря на некоторые её недостатки, она была выбрана неслучайно — это мощнейшая база данных, способная хранить и обрабатывать колоссальное количество записей данных наших клиентов, среди которых есть очень крупные компании с неординарными требованиями к аналитике. В общем, нам есть, что рассказать.

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

  • Определение состояния бизнеса. Совокупность полученных и интерпретированных данных отображает реальное положение дел в бизнесе: от выполнения плана продаж до прибыли и состояния складских запасов. Каждая компания, начиная бизнес, должна иметь систему показателей-маркеров и их нормативных значений, чтобы периодически оценивать ситуацию. Возьмём, к примеру, рекламное агентство. Примерный список маркеров: отношение входящих лидов и активных клиентов, количество оплаченных счетов, дебиторская задолженность, прибыль, количество текущих и закрытых проектов (воронка), суммарные выплаты сотрудникам на аутсорсе и фрилансерам. Как вы заметили, мы в одном примере смешали финансовые и маркетинговые показатели. Конечно, в реальной жизни их лучше разделять.
  • Выявление проблем бизнеса — следующий этап после оценки состояния. Если показатели отклоняются от нормативных значений, следует рассматривать каждое отклонение как проблему, даже, если она таковой на первый взгляд не кажется. Например, в рекламном агентстве значительный рост количества клиентов (хорошо) может привести к формированию дебиторской задолженности или же неисполнения заказов в срок и возникновению репутационных рисков. Особенно ценным для выявления проблем является прогнозирование. Умение предвидеть ситуацию на основе существующего пула данных избавляет компанию от множества проблем и оставляет время для манёвров.
  • Рекомендации по улучшению ситуации также формируются на основе анализа информации и обращения к пулу существующих данных. В принципе, ни одна маркетинговая акция не должна проходить без предварительного глубокого анализа и прогнозирования результатов. С одной стороны, это гарантия осознанности решения, с другой — возможность ещё раз продумать все основания для проведения активности. Та же самая ситуация и в иных коммерческих вопросах: для изменения каналов продаж, кредитования покупателей, предоставления скидок и формирования новых методов продаж (типа рассрочки) должна быть обязательная аналитическая основа с краткосрочным, среднесрочным и долгосрочным прогнозом.
  • Определение стратегии, потребностей бизнеса в целом — ещё одна важная задача аналитики. На основе данных базируются решения о реструктуризации компании, кадровых изменениях, закупках оборудования, ликвидации активов и многого другого. В крупных компания главным аналитическим сводом является бюджет и бизнес-план, которые порой достигают сотен страниц описания и расчётных листов и файлов. Небольшие компании избегают бюджетного процесса и в чём-то они правы (он отнимает время и требует серьёзного подхода к формам, формулам, взаимодействию). Но полностью отказываться от планирования и бизнес-анализа нельзя. Как вести его проще мы расскажем ниже.

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

Кому нужна сквозная аналитика?

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

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

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

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

Сайты крупных коммерческих компаний и сетей также не являются исключением и должны оснащаться системой аналитики. Особенно в том случае, когда ведётся активная деятельность через интернет-каналы. Зачастую компании-гиганты работают с «Big Data» и для сбора всей возможной аналитики используют собственные сервера и кластеры.

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

Настройка сквозной аналитики на базе «google marketing platform»


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

Те люди, кто хорошо знаком с воронкой продаж, сразу же заметят все основные элементы для её построения.

Сквозная веб-аналитика должна собирать следующие сведения:

  • посещаемость сайта за отчётный период (трафик);
  • количество заявок, онлайн-заказов, телефонных звонков и прочих видов обращений;
  • расходы на одну конверсию;
  • доходы;
  • сведения, накопленные в CRM о статусах сделки.
Дополнительный анализ:  Маркетинг-аналитика в бизнесе: особенности внедрения и развития | OWOX BI


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

Общий принцип работы сквозной аналитической системы:

  • присвоение посетителю веб-сайта уникального идентификатора (ID);
  • фиксация действий в системе учета клиентов;
  • уточнение сведений с источника трафика (например, их передача с рекламной площадки, с который был осуществлен переход);
  • возврат в систему аналитики данных о сделках и получаемых доходах;
  • формирование отчёта о доходах/расходах в разрезе для каждого канала маркетинговой коммуникации;
  • расчёт ROI и KPI работников (при наличии информации, свидетельствующей об эффективности работы менеджеров по продажам).

Итак, разобравшись с общей схемой построения сквозной аналитики, рассмотрим главный её элемент – «Система аналитики» и то, что может ей служить в тех или иных случаях.


Наиболее простой и доступный инструмент – «Маркетинговая платформа» от «Google».

Для удобства построения системы веб-аналитики для своего сайта, начать стоит с установки «Google Tag Manager». Это универсальный инструмент, позволяющий управлять кодами отслеживания через отдельную панель, не взаимодействуя напрямую с кодом самого веб-сайта.

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


Чтобы произвести подключение «GTM» к сайту, для начала потребуется создать аккаунт в данном сервисе. Для этого нажмем на соответствующую кнопку, авторизовавшись в своей учётной записи в «Гугл».

Сразу после этого вводим название и нажимаем «Далее».

Создаём контейнер и выбираем варианта использования «для веб-сайта».

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

Отслеживание обращений по электронной почте

Отслеживание обращение по электронной почте – ещё один важный атрибут построения системы сквозной аналитики. Как показывает практика, есть два способа начать вести переписку с компанией. Первый связан с копированием адреса электронной почты и вставкой его в «Отправители». Второй вариант подразумевает щелчок по адресу и переходу к написанию письма в новом окне.

Начнем с мониторинга кликов по email-адресу, настройка которых осуществляется через установленный нами ранее «Google Tag Manager». Для этого потребуется создать событие. Заходим в раздел «Переменные» и нажимаем кнопку «Настроить».

Выбираем вариант «Click URL».

Сразу после этого переходим в «Триггеры» и в настройках выбираем «Только ссылки».


Выбираем «Некоторые клики по ссылки» и устанавливаем «Click URL» содержит «mailto».

Сразу после этого переходим к созданию тегов и устанавливаем отслеживание кликов по e-mail.

В конфигурации задаём веб-аналитику. Прописываем:

  • тип отслеживания – «Событие»;
  • категория – «Clicks»;
  • действие – «EmailClick»;
  • ярлык – «mailClick».

В завершении настроек останется лишь только добавить идентификатор системы аналитики, скопировав его в настройках «Google Marketing Platform». Это действие позволит синхронизировать аналитику и события, связав их вместе в единый функционирующий организм.

Вставляем специальный скрипт, изображенный ниже.

Далее, как и в прошлый раз, – выбираем тип «Пользовательское событие».


Теперь создаем триггер.

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

Улучшить отслеживание можно, задав соответствующие цели в «Google Marketing Platform», для чего достаточно выбрать соответствующий пункт и следовать всплывающим подсказкам.


Таким образом, мы получили бесплатный email-трекер.

Системная аналитика

image

  • При постановке задачи на front и back старайтесь описывать sequence диаграммы

Или, по-русски, диаграммы последовательности. Диаграммы окажутся полезными даже не с точки зрения разработки, но с точки зрения верификации собственных требований. Очень часто при описании потока сообщений я выявлял «дыры» в собственном процессе. Например, неактуальный API.

Для быстрого «рисования» sequence диаграмм используйте плагин PlantUML для Confluence. Мне показалось, что быстрее набирать код, нежели ручками корректировать расположение блоков и стрелок. Но у каждого в этой части свой опыт и свои предпочтения.


С точки зрения анализа

позволит вам закрывать ваши же дыры в требованиях. Где-то упустили атрибут, где-то забыли создать задачу в JIRA для доработки базы данных. Не пытайтесь зазубрить синтаксис Сваггера, а создайте шаблоны под разные типы API (справочники, фильтры и так далее), чтобы упростить себе жизнь в будущем.

  • Активно используйте инструмент разработчика в целевом браузере, чтобы анализировать запросы клиента и ответы от сервера

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

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

Во-вторых, вы сможете убедиться в правильной последовательности вызовов. Ведь вы сами описали её в рамках sequence диаграммы.

Этот подход позволил нашей команде выводить достаточно хитрые доработки в пром в рамках спринтов без задержек.

Схемы взаимодействия аналитик – команда

В Agile большое внимание уделяется командной работе, самоорганизации. Как организовать взаимодействие аналитика с командой с учетом возлагаемых на него функций? Есть разные варианты, причем в зависимости от обстоятельств, эффективными оказываются те или иные.

Владелец продукта — аналитик

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

Т. ч. можно решить: функции аналитика исполняет владелец продукта. Или, если угодно, наоборот — аналитик исполняет роль владельца продукта.

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

Недостатки:

  • ­Слишком многое зависит от одного человека — большая нагрузка и связанные с этим риски «бутылочного горлышка».
  • Экстремальная незаменимость — а если в отпуске, а если заболел.
  • Вряд ли получится плотно привлечь такого владельца продукта к сопровождению системы или активному участию в пилотных внедрениях.
  • Есть вероятность, что владелец продукта будет откладывать решение каких-то задач не потому что у них низкий приоритет, а потому что он пока еще не успел как следует проработать постановку. Т. е. убивается вся идея приоритизации работ на основании потребностей бизнеса, а не исходя из внутренних или технических обстоятельств.

Аналитик — помощник владельца продукта

Большинство недостатков предыдущей схемы можно преодолеть, если поделить обязанности владельца продукта и аналитика между двумя людьми — достаточно распространенная практика. Как правило, при этом «главный» решает, что в какую очередь делать, и дополнительно выполняет менеджерские функции. А помощник больше концентрируется на содержании и деталях работ, т. е. играет роль аналитика.

Однако, и у этой схемы есть недостатки:

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

Аналитик внутри команды

Можно пойти еще дальше и поместить аналитика внутрь команды. Что это значит:

  • Аналитик сидит вместе со всеми, т. е. в одной комнате с разработчиками.
  • Аналитик участвует в Scrum-митингах с остальными (рассказывает, что делал вчера и что собирается делать сегодня).
  • Работа аналитика учитывается при планировании итерации.
  • Аналитик может привлекаться к нехарактерным для себя работам, чтобы помочь остальной команде в непростую минуту — например, подготовить тестовые данные, прогнать часть ручных тестов.

Звучит здорово. И работает здорово! Однако бывают обстоятельства, при которых схема не подходит:

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

Заключение


Так есть разница между аналитиком в Agile и не-Agile (например, в водопаде или другой тяжеловесной методологии)? Однозначный ответ — есть!

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

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

Аналитик в Agile — золотая середина между крайностями:

Одна крайность Золотая середина Другая крайность
Команду не допускают к аналитической работе. Agile Разработчикам самим приходится полностью прояснять, что же нужно.
Аналитик мало общается с заказчиком. Agile Аналитик всё время проводит у заказчика.
Подробные спецификации перед началом итерации. Agile Отсутствие какой-либо проработки требований до постановки их в итерацию.
Команда «с придыханием» относится к установкам аналитика. Agile Команда не доверяет результатам работы аналитика (не использует их).
Аналитик не участвует в тестировании (QA). Agile Аналитик вынужден постоянно «протыкать» много старых интерфейсов.
Команда воспринимает аналитика как руководителя. Agile Аналитик для команды — мальчик/девочка «на побегушках».
Аналитик взаимодействует с командой исключительно при помощи документации и баг-трекера. Agile Аналитик взаимодействует с командой исключительно посредством устных коммуникаций.
С заказчиком и пользователями общается только аналитик. Agile Все члены команды вынуждены плотно общаться с заказчиками и пользователями.
Оцените статью
Аналитик-эксперт
Добавить комментарий

Adblock
detector