RSS

Список задач для перехода в облако

14 января 2020 gromych

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

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

  • Определите свои бизнес-цели. Как облако вписывается в вашу бизнес-стратегию?
  • Определите свой бюджет – начальные инвестиции, одобрение OpEx/CapEx и другое.
  • Оцените свое текущее аналитическое решение – что уже находится в облаке, что находится у вас в локальном доступе и т. д.
  • Планирование облачной среды. Какие части будут в облаке?
  • Определите те отделы, которые затронет перенос – кто руководит работой, кто использует ее результат и т. д.
  • Проверьте ваши данные – количество, источники и типы данных.
  • Учтите безопасность и конфиденциальность – уникальные требования, стратегии резервного копирования и многое другое.
  • Планирование пути переноса – переходы в облако будут более успешны, если у вас есть план.


Читать далее »

Картографирование в помещении с помощью QlikMaps

13 января 2020 gromych

Узнайте, как идет бизнес в микро-масштабе

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

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

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

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

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

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

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

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

Просмотр показателя транзита для стратегического размещения рекламы

Сделайте больше, чем просто карту

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

Читать далее »

Хранилище данных – нужно ли оно вам?

10 января 2020 gromych

Принимаете ли вы бизнес-решения на основе данных из электронных таблиц или отдельных баз данных с нестандартными структурами и форматами? Видите ли вы несогласованность данных в разных отделах? Как вы решаете вопрос с разрешениями и уровнями доступа к ограниченным данным?

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

Что такое хранилище данных?

У компаний есть приложения, которые обрабатывают и хранят тысячи, даже миллионы транзакций каждый день. Возможность создавать, извлекать, обновлять и удалять эти данные стала реальностью благодаря базам данных, также называемым онлайн-системами обработки транзакций (OLTP). Хотя эти базы данных традиционно были реляционными (SQL Server, Oracle, MySQL, DB2 и т. Д.), в последнее время популярность получили нереляционные базы данных (Cassandra, MongoDB, Redis и т. д.) или файловые системы (такие как Hadoop) как альтернатива для хранения необработанных данных.

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

  1. Корпоративное хранилище данных – предоставляет центральное хранилище, предназначенное для поддержки принятия решений для всей компании.
  2. Оперативное хранилище данных – аналогично корпоративному хранилищу по объему, но данные обновляются почти в реальном времени и могут использоваться для оперативной отчетности.
  3. Витрина данных – это подмножество хранилища данных, используемое для поддержки определенного региона, бизнес-единицы или функциональной области (т. е. продажи).

Каковы основные различия между системами OLTP и OLAP?

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

С другой стороны, базы данных (OLTP) – это отдельные приложения, созданные для быстрой записи определенных бизнес-процессов, таких как транзакции по банковским картам. Кроме того, в отличие от ненормализованной природы хранилищ данных, структура данных для баз данных сильно нормализуется, что упрощает атомарность данных, изоляцию согласованности и долговечность. Из-за сложности написания запросов для анализа в таких приложениях разработчики или эксперты в данной области чаще всего нуждаются в поддержке.

Где находятся хранилища данных?

Поскольку объемы данных растут в геометрической прогрессии, хранилище данных становится критически важным, и следует учитывать оборудование, которое хранит, обрабатывает и обеспечивает средство перемещения данных. Хранилища данных могут размещаться на локальных ресурсах, в облаке или в сочетании этих двух сред. Ваше решение может зависеть от требований по хранению критически важных приложений организации на месте. Если вы ищете облачные решения, примите во внимание промышленные нормы, безопасность, видимость, доступность, задержку и надежность поставщиков облачных услуг. (Вот некоторые из ведущих поставщиков облачных услуг: Amazon Web Services, Google Cloud Platform, Microsoft Azure, Oracle Cloud, Rackspace, Verizon Cloud и VMware.)

Так как же выглядит типичная реализация хранилища данных?

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

Сбор данных

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

Чистка

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

Хранение

Слой Хранения представляет денормализованное хранилище данных, которое описано далее в этом посте. Хотя есть несколько моделей проектирования, подход Kimball – самый популярный вариант, в котором информация организована в таблицы измерений и фактов и объединена в звездообразные схемы для простоты использования.

Распространение

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

Преимущества наличия хранилища данных

Хранилища данных помогут вам принимать более обоснованные решения по многим причинам:

  • Улучшенная бизнес-аналитика: при интеграции нескольких источников вы принимаете решения на основе ВСЕХ ваших данных.
  • Своевременный доступ к данным: быстрый доступ к критически важным данным в одном централизованном месте.
  • Повышение качества и согласованности данных: данные по всей организации стандартизированы и хранятся в одном и том же формате, поэтому все отделы принимают решения на основе единых данных.
  • Исторический анализ: поскольку хранилище данных хранит большие объемы старых данных, вы можете определить тенденции с помощью анализа по сравнению с прошлым годом.
  • Быстрое время отклика на запрос. Большинство хранилищ данных моделируют, строят и оптимизируют для доступа и чтения, что означает быстрое создание отчетов.
  • Анализ данных: вы можете исследовать «Большие данные», чтобы предсказать будущие тенденции.
  • Безопасность: хранилище данных упрощает представление, предоставляя доступ к определенным данным квалифицированным конечным пользователям, исключая при этом другие.
  • Аудит: данные, хранящиеся надлежащим образом в хранилище данных, обеспечивают полный журнал аудита, когда именно данные были загружены и из какого источника (источников).
  • Поддержка аналитических инструментов: аналитические инструменты, которые предлагают возможности детализации, работают лучше всего при извлечении данных из хранилища данных.
  • Требования государственного регулирования: благодаря хранилищу данных легче соблюдать требования Сарбейнса-Оксли и других связанных с этим правил, чем с некоторыми транзакционными системами.
  • Создание метаданных: описания данных могут храниться в хранилище данных, чтобы пользователи понимали данные в хранилище, что значительно упрощает создание отчетов.
  • Масштабируемость: если у вас есть объемы исторических данных, требующие консолидации, хранилище данных обеспечивает легкий доступ в общем месте и возможность масштабирования в будущем.
  • Производительность в режиме реального времени. Хранилище данных может объединять данные с разнородных источников с возможностями сохранения истории, как только данные станут доступны.

Что может произойти, если у вас нет хранилища данных

Давайте рассмотрим примерный сценарий: у компании XYZ есть три системы, которые используются для отслеживания потенциальных клиентов, в процессе продаж:

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

Четкого набора правил, чтобы определить, какой тип данных должен существовать в каждой из трех систем и когда данные должны перемещаться из приложения 1 в приложение 2 не существует. Из-за отсутствия согласованности и правил компания XYZ сталкивается со следующими проблемами:

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

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

3 вопроса, которые нужно задать, рассматривая хранилище данных

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

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

1. Храните ли вы данные в различных исходных системах?

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

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

2. Испытываете ли вы проблемы с производительностью при составлении отчетов по операционным системам?

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

3. Есть ли у вас единый «источник правды»?

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

Альтернативы традиционному хранилищу данных

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

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

Озера данных

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

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

  1. Все данные извлекаются и загружаются из исходной системы
  2. Все типы данных поддерживаются
  3. Преобразование и моделирование данных выполняется в соответствии с требованиями анализа

Самообслуживание в BI

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

  1. Случайные пользователи – обладают ограниченным набором навыков BI и требуют простых условий
  2. Опытные пользователи – опытные пользователи BI с возможностью анализировать данные и создавать новые отчеты и информационные панели с нуля.
  3. Бизнес-аналитики – имеют продвинутые навыки BI в области исследования, моделирования и развертывания сред BI.

Вот некоторые из самых популярных инструментов самообслуживания BI, доступных на рынке: Qlik, Tableau, Power BI, Sisense, Ateryx и Birst.

Нереляционные (без SQL)

Нереляционные БД – это архитектурный подход к проектированию баз данных, который не основан на традиционном представлении данных. Системы управления реляционными базами данных организуют данные в виде таблиц, столбцов, строк или схем для операций CRUD (создание, чтение, обновление и удаление). Для сравнения, базы данных NoSQL основаны не на реляционных структурах, а на более гибких моделях данных, обеспечивающих скорость, масштабируемость и гибкость. Это ключевые характеристики, необходимые для работы с «большими данными».

На рынке сегодня доступны различные типы баз данных NoSQL, и они делятся на четыре основные категории:

  1. Нереляционная база данных типа «ключ-значение» – эти базы данных используют связи между элементами в качестве модели данных, так что ключ связан только с одним значением в наборе. Обычно сохраненное значение является BLOB-объектом. Это означает, что никто не знает, каково значение данных, пока ключ не будет представлен в качестве идентификатора для обеспечения доступа. Базы данных типа «ключ-значение» включают DynamoDB, Azure Table Storage, Riak, и Redis.
  2. Базы данных документов – они хранят и извлекают документы в нескольких форматах, таких как XML, JSON и BSON. Вот популярные примеры таких хранилищ документов – Elastic, MongoDB, CouchDB, Terrastore, RavenDB, и Azure DocumentDB.
  3. Широкоформатные базы данных. Эти базы данных хранят данные в таблицах со строками и столбцами, аналогично традиционным реляционным базам данных. Однако имена и форматы столбцов могут варьироваться от строки к строке в таблице. Другими словами, столбцы связанных данных сгруппированы вместе, что позволяет извлекать связанные данные в одной операции запроса. С другой стороны, реляционные базы данных хранят строки в разных местах на диске, которые требуют многократного ввода-вывода для извлечения данных. Вот примеры таких БД: Hadoop, Cloudera, Cassandra, HBase, Amazon DynamoDB и Hypertable.
  4. Базы данных графиков. Эти базы данных используют структуры графиков для хранения, сопоставления и запроса взаимосвязей между объектами. Вот примеры таких БД: Sparksee, InfiniteGraph, New4J и OrientDB.

Читать далее »

Как снизить риск при подготовке данных вручную

9 января 2020 gromych

Почему ручное управление недостаточно хорошее?

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

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

  • Самая большая проблема с ручной подготовкой данных заключается в том, что одному или нескольким людям необходимо уделить время для обработки данных, для того, чтобы использовать их в различных отчетах. Это также означает, что они потратят время на анализ данных и принятие обоснованного и своевременного решения (при условии, что данные верны). Эта «двойка» стоит денег с обеих сторон уравнения, потому что тратятся часы не только на подготовку данных, возникают дополнительные расходы в будущем в том случае, если данные не получены время. Первое относительно легко вычислить, а второе – нет.
  • Если данные не являются общедоступными, а бизнес-логика не централизована, группы могут сообщать о разных и конфликтующих наборах данных. Один отдел или пользователь может вычислить что-то одним способом, а другой – другим. Отсутствие единого «источника правды» приводит к недоверию к данным и, как правило, приводит к ручному манипулированию ими, поэтому пользователи могут чувствовать себя уверенно, принимая решение или рекомендацию. Со временем это, как правило, приводит к разрозненности данных и усложняет межведомственное согласование и сотрудничество.
  • Ручные процессы неизбежно означают неточности или ошибки в расчетах и отчетности. Простые ошибки, такие как неудачное копирование и вставка или неправильный VLOOKUP, со временем усугубляются и могут остаться незамеченными, пока не станет слишком поздно. Если данные за год или квартал обозначены желтым или красным цветом, вряд ли вас ждет приятный разговор с боссом. Но хорошая новость заключается в том, что большинство, если не все, эти потенциальные риски можно уменьшить, максимально автоматизировав процессы обработки данных.

Шаги для автоматизации

  • Очистите ваши данные. Очистите данные в источнике и установите правила и процессы на месте, чтобы гарантировать, что данные остаются без изменений (насколько это возможно). Например, «WI», «Wi», «Висконсин», «Висконсн» и другие варианты могут не бросаться в глаза, но для точного отчета все они должны быть в одном формате. Даже если всего несколько значений не соответствуют требованиям, это может иметь негативные последствия при составлении отчетов. Определите параметры для полей, убедитесь, что числовые поля получают числовые значения, и сделайте важные поля обязательными. Как только правила вступят в силу, найдите время для очистки устаревших данных. Этот процесс может занять некоторое время, но вам нужно будет сделать это только один раз.
  • Выберите правильные инструменты. То, какой инструмент будет лучше, зависит от множества разных вещей, но суть в том, что инструменты могут автоматизировать задачи очистки и гарантировать, что введенные данные будут в правильном формате в базе данных для хорошей отчетности. Эти инструменты могут выполнять аудит отчетов, чтобы выявлять проблемы с данными, быстро решать их и гарантировать, что одна и та же ошибка не повторяется.
  • Централизация бизнес-логики. Подобно инструментам автоматизации, есть множество различных инструментов и методологий, которые можно использовать для централизации бизнес-логики. Независимо от того, вкладываете ли вы средства в полноценное хранилище данных или используете SQL для создания метрики, единственное определение метрики с централизованным хранением гарантирует, что все используют одни и те же значения в своем анализе. Теперь вместо того, чтобы пользователи проводили собственный анализ, хранилища данных исключаются, и все сотрудники организации находятся в одной аналитической среде. Это означает, что больше нет звездочек рядом с числами на межведомственных совещаниях и есть консенсус по самым важным метрикам.
  • Предоставьте пользователям больше возможностей для анализа. Чем больше пользователей адаптируется, тем больше инструментов и процессов можно усовершенствовать. Предоставив пользователям возможность (и время) анализировать данные вместо того, чтобы тратить время на манипулирование ими, они смогут быстрее составлять отчеты, быстрее адаптироваться к постоянно меняющейся бизнес-среде и в конечном итоге делать больше полезного с данными. Все предыдущие шаги, перечисленные в этой статье, позволяют пользователям делать это и делать уверенно.

Читать далее »

Запуск вашей программы управления данными за 8 шагов

23 декабря 2019 gromych

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

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

Управление данными следует внедрять сверху вниз.

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

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

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

5. Функциональный дизайн. Функциональный дизайн – возможно, самый важный шаг во всем процессе. Здесь рассматриваются функции и процессы (а не люди), которые должны быть в наличии для разработки и развертывания вашей программы управления данными. Группа развертывания определит основной список того, как будет происходить управление данными, определит функции и процессы управления информацией, а также определит роли и обязанности. Как только дизайн программы станет понятным, убедитесь, что он соответствует позиции менеджмента. Если у вас не будет заинтересованности руководства, скорее всего, ваша программа управления данными потерпит неудачу.

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

7. Дорожная карта: на этом этапе планируются детали событий «Управление данными». Дорожная карта должна включать требования и основу для поддержки вашей программы управления данными. Схема дорожной карты может включать в себя следующие шаги:

  1. Интеграция управления данными с другими данными
  2. Разработка метрики управления данными и требований к отчетности
  3. Определение поддерживающих требований
  4. Разработка плана управления изменениями
  5. Определение операционного развертывания программы

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

Читать далее »

7 советов по созданию надежной инфраструктуры данных

18 декабря 2019 gromych

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

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

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

1. НАЧНИТЕ С НАЧАЛА – определите свою стратегию в отношении данных и аналитики

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

Наш подход к оказанию помощи нашим клиентам в определении их стратегии данных и аналитики состоит из 4 основных этапов:

  1. Определите свое видение – каково видение долгосрочной аналитики и как оно вписывается в вашу общую бизнес-стратегию?
  2. Запишите ваше текущее состояние – сюда входит интервью с заинтересованными сторонами, оценка источников данных и обзор технологий
  3. Разработайте план аналитики – это подробный план, который отображает, куда вы хотите идти, и план для устранения существующих пробелов.
  4. Предоставление результатов – поэтапный подход, чтобы клиенты смогли предоставлять обратную связь на протяжении всего процесса и видеть результаты на своем пути.

С чего начать:

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

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

Узнайте больше о наших услугах по стратегии передачи данных.

2. ПРИОРИТИЗАЦИЯ ВАШИХ ПРОЕКТОВ

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

Зачем расставлять приоритеты?

  • Это увеличивает показатели успешности стратегических проектов
  • Повышает согласованность и направленность управления вокруг стратегических целей
  • Снимает сомнения оперативных команд, когда они сталкиваются с решениями
  • Формирует мышление и культуру исполнения

С чего начать:

Используйте Матрицу приоритетов

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

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

Матрица приоритетов

3. ОЦЕНИТЕ СРЕДУ

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

  • Вопросы настройки безопасности
  • Загрузка данных/стратегия хранения
  • Архитектурная схема
  • Изменение стратегии управления

С чего начать:

Убедитесь, что ваша среда достаточно продумана.

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

4. СОЗДАЙТЕ ГИБКУЮ МОДЕЛЬ ДАННЫХ

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

Примеры моделей данных

Такие инструменты, как Qlik, Tableau, PowerBI, помогут вам получить лучший доступ к своим данным и принять более взвешенное решение. ОДНАКО, если вы не строите реляционную модель данных, решение не будет создано в будущем.

Реляционные модели данных (хранилища данных) и зачем они нужны

Такие инструменты, как Qlik, Tableau, PowerBI, могут помочь вам получить хороший доступ к вашим данным, чтобы лучше принимать решения, но, если вы не создадите реляционную модель данных, решение не будет устойчивым.

Зачем вам хранилище данных:

  • Нет необходимости обращаться к источникам данных по отдельности, это сокращает подготовку данных
  • Автоматически интегрирует разрозненные источники данных по общим атрибутам.
  • Хорошее хранилище данных предназначено для восприятия человеком, а не компьютерной программой.
  • Сокращает время на анализ данных, дает вам уверенность в ваших данных, обеспечивает более высокое качество анализа и обеспечивает лучшую безопасность данных
  • Позволяет управлять данными и предотвращает анализ данных в стиле «Дикого Запада»

С чего начать:

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

Пример матрицы шин

5. ДОКУМЕНТИРУЙТЕ ПРОИСХОЖДЕНИЕ ДАННЫХ

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

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

С чего начать:

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

Пример документа с отображением ETL

6. ВЕРНИТЕСЬ НА ШАГ НАЗАД И ОЦЕНИТЕ ЭФФЕКТИВНОСТЬ

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

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

Пользовательский опыт:

  • Сколько времени занимает запуск отчетов?
  • Какие факторы влияют на производительность?
  • Эти услуги действительно слишком дороги?

Производительность серверной части:

  • Как часто необходимо обновлять данные?
  • Используете ли вы дополнительные нагрузки?
  • Вы загружаете данные, которые никто не использует?
  • Какова будет производительность ETL?

С чего начать:

Начните документировать текущее состояние, взаимодействие с пользователем и производительность серверной инфраструктуры. Соберите показатели производительности, оцените факторы, влияющие на производительность, установите SLA и определите области для улучшения.

7. РЕАЛИЗАЦИЯ ПРОГРАММЫ УПРАВЛЕНИЯ ДАННЫМИ

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

Как реализовать программу управления данными

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

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

Читать далее »

Что нужно учитывать для плавного перехода в облако

17 декабря 2019 gromych

Почему так много компаний переносят свою инфраструктуру данных и аналитики в облако?

Другие компании сделают это лучше

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

Экономия на издержках

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

OpEx вместо CapEx

Упрощенное определение капитальных расходов (CapEx) – это те расходы, которые вы понесете сейчас для реализации выгоды в будущем, а операционные расходы (OpEx) – это расходы, необходимые для поддержки текущих повседневных операций компании. Эти довольно базовые определения объясняют, почему бухгалтерия компании обычно предпочитает проводить расходы как операционные, а не капитальные, но есть и дополнительные преимущества.

CapEx требует, чтобы активы показали эффект в течение налогового года, в котором они были приобретены, и только часть расходов можно вычитать каждый год, их сумма является переменной (часто запутанной и противоречивой!) в зависимости от метода амортизации, который используется бухгалтерией. И наоборот, всю операционную стоимость можно вычесть незамедлительно. Простота учета OpEx – еще одна причина, по которой облачные сервисы на основе подписки привлекательны для бухгалтерии компании.

Перспективная среда

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

Повышенная безопасность

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

Обновления и новые функции

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

Почему некоторые компании не переходят в облако?

Перегружены вариантами

С таким количеством облачных провайдеров, методов и моделей процесс перехода может быть легко заторможен. PaaS и IaaS, SaaS и Public, Private и Hybrid – вот лишь часть из общего многообразия выборов, которые вам предстоит сделать, но вы не первый, кто делает это. Компании всех размеров и сложности успешно переходят в облака с хорошо продуманными стратегиями. Вы можете рассмотреть возможность получения помощи от компании, которая специализируется на создании стратегий данных для инициатив клиентов, включая переход в облако.

Время переходить

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

CapEx вместо OpEx

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

Экспертиза

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

Что следует учитывать при переходе

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

Общественные, частные и гибридные среды

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

  • Общедоступное облако обычно является самым дешевым способом получить масштабируемость и доступность облака, но ваши ресурсы используются совместно с другими облачными клиентами. Вы и ваш облачный провайдер разделяете обязанности по обеспечению безопасности, а облачный провайдер отвечает за базовое оборудование.
  • Частное облако дает вам больше контроля. Аппаратные ресурсы предназначены только для вашего использования, но по более высокой цене, чем публичное облако. Вы по-прежнему получаете выгоду от масштабируемости и доступности, а также изолируете свои данные и вычислительные ресурсы от других облачных клиентов.
  • Гибридное облако – это когда часть ваших ресурсов находится в облаке, а другие остаются локальными. Компании часто выбирают гибридное облако, когда хотят оперативно работать с самыми чувствительными компонентами своей среды или просто хотят использовать существующие серверные ресурсы, пока у них еще есть какая-то полезность.

Облачные платформы

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

Amazon и Microsoft

В настоящее время Amazon и Microsoft доминируют в области облачных вычислений с их всеобъемлющими, надежными облачными платформами, Amazon Web Services (AWS) и Microsoft Azure. Эти продукты включают в себя следующие возможности модели обслуживания «из коробки»:

  • Инфраструктура как услуга (IaaS): хранение данных и виртуальные машины
  • Платформа как услуга (PaaS): пользователи могут разрабатывать собственные приложения
  • Программное обеспечение как услуга (SaaS): пользователи могут запускать программное обеспечение сторонними поставщиками.

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

Microsoft AWS и Microsoft Azure также предлагают множество встроенных инструментов для профилирования данных, интеграции, анализа и визуализации. Хотя эти сервисы являются более новыми для своих платформ, они продолжают выпускать усовершенствования и функции, чтобы конкурировать с существующими инструментами. Одним из преимуществ использования основных облачных платформ является то, что они предлагают варианты SaaS, которые позволяют интегрироваться с существующим программным обеспечением. Например, Informatica, SSIS и другие инструменты интеграции данных совместимы с AWS и Azure; а инструменты визуализации данных, такие как Qlik, Tableau и Power BI, могут использовать данные, хранящиеся в облаке.

Google Cloud

Google Cloud (GCP) быстро становится еще одной жизнеспособной альтернативой. Пакет GCP расширяется с каждым днем (средство создания отчетов Looker является частью GCP с июня 2019 года) и уже предлагает те же базовые функции и сервисы, что и AWS и Azure. Однако GCP использует кабельную систему FASTER, которая может поддерживать скорость до 10 Тбит/с по сравнению со 100 Гбит/с для AWS и 263 Гбит/с для Azure. Это означает, что пропускная способность сети в 100 раз выше, что отлично подходит для данных в реальном времени и веб-приложений с высоким трафиком. Благодаря Live Migration GCP автоматически перенесет ваши приложения в новое хранилище без простоев и задержек.

Snowflake

Snowflake («Снежинка») – это не облачная платформа с полным стеком, а хранилище данных, созданное специально для облака. Оно предлагает мгновенную масштабируемость, доступность и поистине автоматическую эластичность. Оно построено на основе AWS и Azure (и GCP в 4 квартале 2019 года). Если вы уже храните данные в облаке, их легко можно перенести в Snowflake. Как только ваши данные будут загружены, вы можете в несколько щелчков мыши создать виртуальное хранилище (вычислительную мощность Snowflake) и приступить к анализу ваших данных.

Хотя и Azure, и AWS имеют собственные запатентованные хранилища данных, Snowflake предлагает некоторые ключевые преимущества, которые еще не предлагались в Azure Data Warehouse, AWS Redshift и Google BigQuery:

  • Большой срок хранения данных (до 90 дней)
  • Поддержка запросов, структурированных и полуструктурированных данных
  • Клонирование нулевой копии – снимок таблицы без дублирования данных.
  • Обмен данными с пользователями за пределами вашей сети

Если ваша организация владеет конфиденциальными данными, у Snowflake есть уровни поддержки HIPAA, соответствия PCI и даже выделенных виртуальных серверов.

Советы по плавному переходу в облако

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

Определите свои бизнес-цели

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

Определите свой бюджет

Для создания облачной среды могут потребоваться значительные начальные инвестиции. Все ваши данные должны быть в облаке, или вы можете начать с одного источника в качестве подтверждения концепции? Легче ли получить одобрение OpEx или CapEx для финансирования перехода в облако? Будете ли вы продолжать финансировать облако и аналитику в будущем?

Оцените свое текущее аналитическое решение

Что уже есть в облаке, и что вы планируете туда перевести? Как вы будете структурировать свои данные в облаке и как будут храниться данные из разных источников данных? Как ваши данные попадут в облако и как они будут использоваться из облака?

Планируйте свою облачную среду

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

Определите какие отделы будут участвовать в процессе

Кто будет вовлечен в процесс и, кто будет использовать результат? Как будут управлять вашими приложениями и данными? Это обусловлено задачами бизнеса или ИТ? Необходимо учитывать количество пользователей (параллелизм) и вычислительные ресурсы, которые они используют, чтобы полностью использовать преимущества перехода в облако.

Просмотрите ваши данные

Ваши данные поступают из разных источников? Нужно ли как-то преобразовывать (подготавливать) данные перед конечным использованием? Ваши данные структурированы, полуструктурированы или неструктурированы? Какой объем данных вы будете хранить в облаке?

Подумайте о безопасности и конфиденциальности

Проблемы безопасности данных сейчас актуальна как никогда. Облачные платформы отвечают вашим требованиям безопасности данных? Есть ли в вашей отрасли особые требования к безопасности? Удовлетворят ли SLA ваши потребности в доступности данных? Каковы ваши стратегии резервного копирования?

Подумайте об аутентификации

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

Планируйте способ перехода

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

Читать далее »

Прогноз и контроль оттока клиентов с помощью машинного обучения

21 ноября 2019 gromych

Машинное обучение

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

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

Традиционная и расширенная аналитика

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

 

Пример сценария: отток клиентов в телекоммуникационной компании

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

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

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

Традиционная аналитика: обзор оттока клиентов за последний месяц

 

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

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

Традиционная аналитика: данные оттока клиентов за последний месяц

 

График вверху этого изображения показывает распределение – те, кто ушли, представлены красным, а те, кто остался – синим. Чем больше разброс, тем меньше отток, и наоборот – чем меньше разброс, тем больше отток (что указывает на проблему).

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

На этой панели показаны клиенты с разбивкой по типу интернет-услуг, которые они используют.

Традиционная аналитика: сведения о типе интернет-сервиса

 

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

На этой панели показаны клиенты с разбивкой по типу оплаты.

Традиционная аналитика: разбивка по типам платежей

 

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

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

 

Введение в машинное обучение в данных

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

Модель машинного обучения оценивает данные и добавляет число достоверности оттока

 

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

Пороговые значения доверительной вероятности позволяют проводить анализ «что, если»

 

Идем дальше – каков профиль наших лояльных и постоянных клиентов?

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

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

 

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

Модели машинного обучения могут автоматически создавать логические группировки и ассоциации

 

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

 

Больше вопросов к данным

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

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

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

 

Читать далее »

7 элементов стратегии данных

21 ноября 2019 gromych

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

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

 

Начните со стратегии данных

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

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

 

Станьте аналитически более зрелыми

Стратегия данных должна включать в себя подробный план развития аналитических способностей и переходить от принятия решений на основе ретроспективных исследований, к принятию решений на основе прогнозов на будущее. Как видно из модели Gartner Analytic Ascendancy, цель должна заключаться в том, чтобы перейти от использования описательной аналитики («что случилось?») к предписывающей аналитике («как мы можем это сделать?»).

Аналитическая модель Gartner

 

7 элементов стратегии данных

  1. Деловые требования

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

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

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

 

  1. Источники и сбор данных

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

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

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

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

Просмотрите вопросы, которые требуют ответов, документируйте необходимые данные и определите пробелы в исходной матрице:

 

  1. Требования к технологической инфраструктуре

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

  • Как операционная система может поддерживать аналитические потребности? Скорее всего, очень слабо. Как правило для удовлетворения аналитических потребностей не рекомендуется использовать операционную систему, а это означает, что вам пригодится центральное хранилище данных.
  • Есть ли в организации навыки и техническая инфраструктура для поддержки хранилища данных у себя в компании, или целесообразнее использовать облачное решение?
  • Как будут заполняться пробелы в тех местах, где сегодня не хватает данных? Можно ли рассчитать или оценить данные? Можно ли купить их на рынке или получить макроэкономические данные? Можно ли реализовать новую исходную систему для генерации данных?
  • Существует ли стандартный инструмент интеграции для передачи данных из исходных систем в центральное хранилище? Будет ли этот уровень архитектуры использоваться для бизнес-логики, чтобы данные были готовы к использованию?
  • Как вы будете предоставлять доступ к данным? Будут ли ИТ-специалисты создавать отчеты, или вы включите самообслуживание? Будут ли эти отчеты достаточными (пригодными для печати) позволят ли они пользователю взаимодействовать с данными? Будут ли они встроены в веб-сайты и предоставлены людям вне сети?

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

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

Концептуальная архитектура данных

 

  1. Превращение данных в понимание

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

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

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

  1. Люди и процессы

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

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

 

Пример учебного плана

 

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

  1.  Управление данными

Управление данными – это то, что в конечном итоге позволяет обмениваться ими на уровне предприятия, это масло, которое смазывает механизм аналитической практики.

Программа управления данными обеспечит следующее:

  • Расчеты, используемые по всей компании, определяются на основе входных данных по всей компании;
  • Правильные люди получат доступ к нужным данным;
  • Будет определено происхождение данных (откуда появились и как они преобразовывались с момента создания).

Мы не ищем инструмент для решения проблем управления данными; это результат работы людей, и это должно произойти. Управление данными становится главным, а иногда и помогает в сложных разговорах.

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

  1. Дорожная карта

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

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

Вот еще факторы для включения в дорожную карту:

  • Наличие персонала и необходимость внешней помощи
  • Процесс составления бюджета компании, особенно если требуются капитальные вложения
  • Конкурсные проекты, которые могут помешать участию нужных ресурсов

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

Пример проекта

 

 

Читать далее »

Советы и стратегии по переходу на корпоративное использование Qlik

8 ноября 2019 gromych

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

 

Создайте свою BI стратегию

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

Вот некоторые элементы, которые мы хотели бы рассмотреть с нашими клиентами при разработке стратегии:

  • Задачи: мы начинаем с того, что задаем вопросы типа «Почему?», или «Чего пытается достичь бизнес?», «Как мы собираемся использовать эти данные для улучшения бизнеса?». Это помогает нам перед поиском решения понять приоритеты. Мы всегда начинаем с расспросов клиентов.
  • Обзор решения. Мы гарантированно добиваемся того, что клиенты понимают возможности Qlik и пути того, как он может помочь бизнесу.
  • Лучшие практики: мы также обучаем клиентов лучшим практикам, таким как денормализация исходных таблиц и перемещение сложных вычислений из пользовательского интерфейса в сценарий загрузки, чтобы пользователи начинали с правильных методов и не создавали для себя лишней работы.
  • Управление: мы обсуждаем, как разработать структуру управления, которая позволит вам включить аналитику самообслуживания, а также обеспечить контроль, надежность и безопасность данных.
  • Архитектура данных: мы обсуждаем такие вещи, как: место хранения данных, способ их организации и интеграции, у кого будет доступ к ним, как обеспечить безопасность и многое другое.
  • Расширения: перед созданием решения вы можете реализовать «стандартный» Qlik, но расширения позволяют использовать его такими способами, которых нет в стандартной реализации. Общие расширения включают QlikMaps, расширенные объекты KPI и те, которые записывают пользовательские данные обратно в базу данных из пользовательского интерфейса Qlik.
  • Обучение. Мы обсудим план обучения для всех пользователей Qlik. Обучение повышает производительность, снижает затраты на обслуживание, увеличивает скорость внедрения и учит пользователей, как максимально эффективно использовать возможности Qlik. Кроме того, чем больше вы знаете, тем меньше вы должны полагаться на консультанта.

Цель такого начала с построения стратегии – содействовать освоению того инструмента, в который вы инвестируете. Рассматривая эти аспекты реализации заранее, вы получите общее видение того, что Qlik даст вам и для чего будет использоваться.

 

Создать матрицу BI приоритизации

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

После того, как вы сопоставили BI цели с корпоративными целями и создали список действий для получения вашего решения, вы оцениваете эти проекты с двух точек зрения:

  1. Как такое поведение повлияет на бизнес?
  2. Какова целесообразность этого? Сколько времени и ресурсов уйдет на получение этой функциональность?

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

Матрица BI Приоритетов помогает вам составить дорожную карту для своих приоритетов и увидеть вещи, которые вы можете легко реализовать.

 

Определить централизованную метрику

После того, как ваш план будет готов, вы захотите внедрить BI платформу таким образом, чтобы она была масштабируема и пригодна для корпоративного использования. Одной из проблем при работе с Qlik является определение централизованной библиотеки для основных элементов, которая может использоваться несколькими приложениями. Одним из методов, который поможет в этом, является служба управляемых метрик, расширение серверной среды Qlik Sense. Она позволяет вам определять ваши метрики извне, загружать их в Qlik Sense и применять их к любым/всем выбранным вами приложениям. Это обеспечивает согласованность (помните «единый источник правды?») и сокращает администрирование, поскольку вам не нужно дублировать сложные основные элементы в приложениях.

Внешние показатели хранятся в архитектуре этого продукта (таблица Excel, таблица базы данных и т. д.); QVD базируется на этом принципе; на сервере установлен инструмент управления управляемыми метриками, и это интерфейс, который вы используете для использования библиотеки метрик в приложениях.

 

Служба управляемых метрик

 

Заранее проверьте масштабируемость вашей системы

Если вы её построите, то, когда появятся новые пользователи… сможет ли ваше железо справиться с таким наплывом? Тестирование масштабируемости необходимо выполнить на ранней стадии процесса реализации, чтобы ответить на неопределенности относительно большего объема памяти или более быстрых процессоров. Набор инструментов для масштабируемости (Scalability Toolkit) поможет вам выполнить регрессионное аварийное тестирование с помощью автоматического тестирования. Этот инструментарий позволяет настроить гипотетический сценарий типичного и нетипичного использования приложения, а затем прогнать этот сценарий, чтобы получить метрики и выходные данные для анализа. Например, вы можете оценить, как увеличившееся количество пользователей влияет на использование ОЗУ и время отклика. Важно протестировать производительность, выявить слабые места и внести соответствующие изменения, прежде чем пользователи начтут взаимодействовать с системой.

 

Управление Qlik с помощью утилит QMC

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

  • App Mover (Перемещение приложений): без этого инструмента вы можете выполнить несколько шагов: экспортировать приложение, присвоить ему имя, сохранить и импортировать его, предоставить соответствующие разрешения и многое другое. App Mover упрощает все эти процедуры, перемещая приложение и всю связанную с ним информацию из одной среды в другую.
  • Object Approver (Подтверждение объектов): при ручном перемещении в другую среду некоторые объекты можно пропустить, поэтому данный инструмент упрощает перемещение всех объектов.
  • Security Rules Manager (Менеджер правил безопасности): воссоздание правил в разных средах утомительно и может привести к ошибкам. Это позволяет легко экспортировать и импортировать правила между средами.
  • Custom Property Bulk Loader (Массовый загрузчик настраиваемых свойств): позволяет вносить массовые изменения в различные компоненты вашей реализации Qlik вместо одного объекта за раз.

 

Автоматический контроль версии С IN4BI

In4BI, доступный для Qlik Sense и QlikView – это инструмент, который позволяет разработчикам работать с одним и тем же документом параллельно с формализованным процессом проверки и некоторыми дополнительными функциями управления. Администраторы действуют как привратники и контролируют продвижение приложений между средами, гарантируя, что QA выполнен и контрольные списки заполнены. Кроме того, номера версий присваиваются автоматически, чтобы избежать путаницы среди разработчиков.

 

Хорошенько подумайте о возможности использования Qlik в облаке

Вполне возможно, что часть вашей системы уже находится в облаке, например, один из ваших компонентов Qlik или другие данные исходной системы (например, данные CRM на Salesforce.com), которые вы загружаете в свою систему. Запуск Qlik в облаке должен стать серьезным фактором при переходе от решения для отдела к решению для всей компании. Размещение компонентов на сервере Qlik в облаке дает вам несколько преимуществ:

  • Упрощение масштабирования, увеличение или уменьшение: добавьте больше вычислительных ресурсов, таких как RAM, CPU и IO, без принятия решений, затрат, времени и установки, связанных с физическими серверами. Вместо этого добавьте пространство, быстро отметив флажок в Интернете, и получите немедленные преимущества. Также есть возможность автоматически запускать и останавливать экземпляры в зависимости от ваших потребностей с помощью недорогих инструментов для самостоятельной работы.
  • Устойчивость и защита от сбоев: в облаке у вас есть кластеры серверов в различных центрах обработки данных. Таким образом, если один центр обработки данных выходит из строя, другие все еще активны. Крайне маловероятно, что два или более центра обработки данных, поддерживающих облачную среду, выйдут из строя одновременно.

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

 

 

Читать далее »
« Предыдущие записи
68 queries in 0,530 seconds