ABC-классификация

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

Пример базового шаблона

Предположим, вы хотите оценить важность того, или иного продукта для дохода вашей компании с помощью ABC-анализа. Вы должны отнести каждый продукт к определенному классу (A, B или C), для которого верно следующее:

  • Продукты класса А составляют 70% доходов.
  • Продукты класса B обеспечивают 20% доходов.
  • Продукты класса C составляют оставшиеся 10% доходов.

В таблице Products («Продукты») создается вычисляемый столбец, который содержит класс ABC, используемый в качестве атрибута группировки в отчетах. Таблица Products («Продукты») связана с таблицей Sales («Продажи»).

Рисунок 1. Таблица Products («Продукты») связана с таблицей Sales («Продажи»)

Чтобы реализовать ABC-классификацию, необходимо создать еще несколько вычисляемых столбцов в таблице Products («Продукты»). Все эти столбцы, кроме ABC Class («АВС-класс»), будут скрыты от клиентских инструментов:

  • ProductSales: общая сумма продаж для продукта (текущая строка).
  • CumulatedSales: общая сумма продаж для всех продуктов одного класса (текущая строка).
  • CumulatedPercentage: значение RunningTotalSales, выраженное в процентах от общей суммы продаж.
  • ABC Class: класс продукта, который может быть A, B или C.

Вы определяете вычисляемые столбцы, используя следующие формулы DAX:

  
 [ProductSales] =
 CALCULATE ( SUM ( Sales[SalesAmount] ) )
  
 [CumulatedSales] = 
 CALCULATE (
     SUM ( Products[ProductSales] ),
     ALL ( Products ),
     Products[ProductSales] >= EARLIER ( Products[ProductSales] )
 )
  
 [CumulatedPercentage] =
 Products[CumulatedSales] / SUM ( Products[ProductSales] )
  
 [ABC Class] =
 SWITCH (
     TRUE (),
     Products[CumulatedPercentage] <= 0.7, "A",
     Products[CumulatedPercentage] <= 0.9, "B",
     "C"
 ) 
Рисунок 2. В вычисляемых столбцах таблицы Products («Продукты») реализована ABC-классификация

Вы можете использовать новый столбец ABC Class («АВС класс») в качестве фильтра в сводных таблицах, как показано на рисунках 3 и 4.

Рисунок 3. У каждой модели продукта могут быть продажи в классах A, B и C


Рисунок 4. Слайсер фильтрует только продукты класса А

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

Примеры использования

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

Управление запасами

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

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

Сегментация покупателей

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

Маркетинговая сегментация

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

Полный шаблон

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

  • <granularity_table> – это таблица, которая определяет уровень подразделения сущностей, которые вы хотите классифицировать. Например, это может быть таблица Products («Продукты»), если вы хотите классифицировать продукты.
  • <granularity_attribute> – это атрибут, который вы хотите использовать в качестве цели классификации (то, что объединяет сущности в меньшее количество элементов). Например, это может быть Products[ProductModel], столбец Product Model («Модель продукта») таблицы Products («Продукты»).
  • <measure> – это значение, которое нужно вычислить для каждого объекта <granularity_table> для ABC классификации.
 [EntityMeasure] =
 CALCULATE ( <measure> )
  
 [CumulatedPercentage] =
 CALCULATE (
     <measure>,
     ALL ( <granularity_table> ),
     <granularity_table>[EntityMeasure]
         >= EARLIER ( <granularity_table>[EntityMeasure] )
 )
     / CALCULATE ( <measure>, ALL ( <granularity_table> ) )
  
 [ABC Class] =
 SWITCH (
     TRUE (),
     <granularity_table>[CumulatedPercentage] <= 0.7, "A",
     <granularity_table>[CumulatedPercentage] <= 0.9, "B",
     "C"
 ) 

Например, вы можете внедрить вычисляемый столбец ABC Product («АВС Продукт») в модели с таблицами Products («Продукты») и Sales («Продажи») следующим образом:

 [ProductSales] =
 CALCULATE ( [Sales Amount] )
  
 [ProductPercentage] =
 CALCULATE (
     [Sales Amount],
     ALL ( Products ),
     Products[ProductSales] >= EARLIER ( Products[ProductSales] )
 )
     / CALCULATE ( [Sales Amount], ALL ( Products ) )
  
 [ABC Product] =
 SWITCH (
     TRUE (),
     Products[ProductPercentage] <= 0.7, "A",
     Products[ProductPercentage] <= 0.9, "B",
     "C"
 ) 
Рисунок 5. ABC-столбец Product («Продукт») оценивает каждую строку в таблице Products («Продукты»)

Если вы хотите рассчитать ABC-классификацию для атрибута сущности, следует использовать немного другой шаблон только для вычисляемого столбца EntityMeasure («Мера сущности»):

 [EntityMeasure] =
 CALCULATE (
     <measure>,
     ALL ( <granularity_table> ),
     <granularity_table>[<granularity_attribute>] 
         = EARLIER( <granularity_table>[<granularity_attribute>] )
 ) 

Например, вы внедряете вычисляемый столбец ABC Model (АВС Модель») в той же модели с таблицами Products («Продукты») и Sales («Продажи») следующим образом:

 [ModelSales] =
 CALCULATE (
     [Sales Amount],
     ALL ( Products ),
     Products[ProductModel] = EARLIER ( Products[ProductModel] )
 )
  
 [ModelPercentage] =
 CALCULATE (
     [Sales Amount],
     ALL ( Products ),
     Products[ModelSales] >= EARLIER ( Products[ModelSales] )
 )
     / CALCULATE ( [Sales Amount], ALL ( Products ) )
  
 [ABC Model] =
 SWITCH (
     TRUE (),
     Products[ModelPercentage] <= 0.7, "A",
     Products[ModelPercentage] <= 0.9, "B",
     "C"
 ) 

Все продукты, которые принадлежат к одной и той же модели, имеют одинаковую классификацию ABC Model (АВС Модель»).

Рисунок 6. Столбец ABC Model («АВС Модель») рассчитывает одинаковое значение для всех продуктов одной модели.

Чтобы использовать ABC-классификацию для одной денормализованной таблицы, необходимо немного изменить определение EntityMeasure следующим образом:

 [EntityMeasure] =
 CALCULATE (
     <measure>,
     ALLEXCEPT ( <granularity_table>, <granularity_table>[<granularity_attribute>] )
 ) 

Например, вы могли бы реализовать вычисляемые столбцы ABC Product («АВС Продукт») и ABC Model («АВС Модель») в модели с одной денормализованной таблицей продаж следующим образом:

 [ProductSales] =
 CALCULATE (
     [Sales Amount],
     ALLEXCEPT ( Sales, Sales[Product] )
 )
  
 [ProductPercentage] =
 CALCULATE (
     [Sales Amount],
     ALL ( Sales ),
     Sales[ProductSales]
         >= EARLIER ( Sales[ProductSales] )
 )
     / CALCULATE ( [Sales Amount], ALL ( Sales ) )
  
 [ABC Product] =
 SWITCH (
     TRUE,
     Sales[ProductPercentage] <= 0.7, "A",
     Sales[ProductPercentage] <= 0.9, "B",
     "C"
 )
  
 [ModelSales] =
 CALCULATE (
     [Sales Amount],
     ALLEXCEPT ( Sales, Sales[Model] )
 )
  
 [ModelPercentage] =
 CALCULATE (
     [Sales Amount],
     ALL ( Sales ),
     Sales[ModelSales]
         >= EARLIER ( Sales[ModelSales] )
 )
     / CALCULATE ( [Sales Amount], ALL ( Sales ) )
  
 [ABC Model] =
 SWITCH (
     TRUE (),
     Products[ModelPercentage] <= 0.7, "A",
     Products[ModelPercentage] <= 0.9, "B",
     "C"
 ) 
Рисунок 7. Столбец ABC Product («АВС Продукт»), реализованный в единой денормализованной таблице.

Рисунок 8. Столбец ABC Model («АВС Модель»), реализованный в единой денормализованной таблице.

3 совета по ускорению отчетов в Power BI

Хотите, чтобы ваши информационные панели Power BI работали быстрее? Следуйте этим рекомендациям.

Лучшие практики использования отношений Fact/Dim в табличных моделях основаны на дизайне Kimball DW. Этот дизайн интегрирован в вычислительный механизм VertiPaq таким образом, чтобы максимизировать производительность по большим наборам данных и многим измерениям, и может использоваться как бизнес-пользователями, так и продвинутыми техническими ресурсами.

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

СОВЕТ №1 ХРАНИТЕ ДАННЫЕ В ЦЕЛОЧИСЛЕННЫХ ЗНАЧЕНИЯХ

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

  • Таблицы фактов должны содержать только целочисленные значения.
  • Все объединения должны базироваться на целочисленных значениях.
  • Даты объединяются в виде целых чисел в формате ГГГГММДД, они хорошо оптимизированы и настроены для проведения очень сложной и комплексной аналитики временных рядов.
  • Размеры строковых значений (даже в измерениях) должны быть максимально уменьшены – 255 – хорошо, 127 – лучше, 31-63 – еще лучше.

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

СОВЕТ №2 РАЗМЕРНЫЕ СВЯЗИ

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

  • Объединения целочисленных значений.
  • Минимизация мощности измерений.
  • Самая высокая производительность достигается при сохранении мощности DIM ниже 127k (выше этого значения производительности начнет ухудшаться).
  • Перемещение атрибутов 2 типа в таблицы фактов и разделение их по измерениям.

СОВЕТ №3 ИЗМЕРЕНИЕ ДАТЫ

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

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

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

Архитектура Power BI – описание 7 компонентов с пояснениями принципа работы

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

Давайте начнем и постараемся сформировать полное понимание концепции.

Архитектура Power BI

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

  • Power Query (для объединения и преобразования данных)
  • Power BI Desktop (инструмент для разработки сопутствующих услуг)
  • Power BI Mobile (для телефонов Android, iOS, Windows)
  • Power Pivot (для моделирования табличных данных в памяти)
  • Power View (для просмотра визуализаций данных)
  • Power Map (для визуализации трехмерных геопространственных данных)
  • Power Q&A (для вопросов и ответов с использованием естественного языка)

Проще говоря, пользователь Power BI получает данные из различных источников данных, таких как файлы, Azure, онлайн-сервисы, DirectQuery или со шлюзов. Затем он работает с этими данными в клиентском инструменте разработки, таком как Power BI Desktop. Здесь импортированные данные очищаются и преобразуются в соответствии с требованиями пользователя.

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

Двигаясь по цепочке процессов, вы можете публиковать отчеты, созданные в Power BI Desktop, на двух видах платформ: Power BI Service и Power BI Report Server.

Power BI Service – это общедоступная облачная платформа, а Power BI Report Server – это локальная платформа, защищенная брандмауэром.

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

Компоненты архитектуры Power BI

Давайте подробнее узнаем о компонентах архитектуры Power BI.

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

Широкий спектр источников данных является важной характеристикой Power BI. Вы можете импортировать данные из файлов вашей системы, облачных сетевых источников данных или напрямую подключаться к действующим соединениям. При импорте данных из локальных или онлайн-сервисов есть ограничение объема в 1 ГБ. Вот некоторые из часто используемых источников данных в Power BI:

  • Excel
  • Text/CSV
  • XML
  • JSON
  • Oracle Database
  • IBM DB2 Database
  • MySQL Database
  • PostgreSQL Database
  • Sybase Database
  • Teradata Database
  • SAP HANA Database
  • SAP Business Warehouse server
  • Amazon Redshift
  • Impala
  • Google BigQuery (Бета-версия)
  • Azure SQL Database
  • Salesforce Reports
  • Google Analytics
  • Facebook
  • GitHub

2. Power BI Desktop

Power BI Desktop – это инструмент на стороне клиента, известный как вспомогательный инструмент разработки.

Это ПО для ПК с инструментами и функциями для подключения к источникам данных, преобразования данных, моделирования данных и создания отчетов.

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

3. Power BI Service

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

Он доступен в трех версиях:

  • Бесплатная версия
  • Pro версия
  • Премиум версия

Power BI Service также известен как «Power BI.com», «Power BI Workspace», «Сайт Power BI» и «Веб-портал Power BI». Этот компонент также предлагает расширенные функции, такие как вопросы и ответы на естественном языке и оповещения.

4. Power BI Report Server

Power BI Report Server похож на Power BI Service. Единственное различие между ними состоит в том, что Power BI Report Server является локальной платформой. Он используется организациями, которые не хотят публиковать свои отчеты в облаке и обеспокоены безопасностью своих данных.

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

5. Power BI Gateway

Этот компонент используется для подключения и доступа к локальным данным в защищенных сетях. Power BI Gateways обычно используются в организациях, где данные хранятся в безопасном режиме под наблюдением. Шлюзы помогают извлекать такие данные по защищенным каналам на платформы Power BI для анализа и составления отчетов.

6. Power BI Mobile

Power BI Mobile – это встроенное приложение Power BI, которое работает на мобильных устройствах iOS, Android и Windows. Приложение используется для просмотра отчетов и информационных панелей.

7. Power BI Embedded

Power BI Embedded предлагает API-интерфейсы, которые используются для встраивания визуальных элементов в пользовательские приложения.

Функционирование архитектуры Power BI

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

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

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

Локальные базы данных

Power BI Desktop – это сопутствующий инструмент разработки и публикации. Вы можете импортировать данные из источников данных в Power BI Desktop и использовать их для создания отчетов, а затем публиковать их в Power BI Service или Power BI Report Server.

Вы также можете публиковать книги Excel непосредственно с помощью Power BI Publisher для Excel на сервере отчетов Power BI. Инструменты SQL Server Data и Report Publisher помогают создавать наборы данных, КПЭ, мобильные отчеты, отчеты с разбивкой по страницам и т.д. Отчеты всех типов публикуются на сервере Power BI Report Server, откуда и передаются конечным пользователям.

Облачные базы данных

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

На облачной стороне архитектуры находится множество компонентов. Полный пакет Power BI содержит потоки данных, наборы данных, информационные панели, отчеты, Power BI Embedded, Power BI Premium и т.д. Вы можете встраивать свои отчеты и информационные панели в Teams, SharePoint, пользовательские приложения и т.д. Они хорошо подсоединяются к инструментам Power BI через прямые подключения.

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

Power BI Service

Как мы узнали из предыдущих разделов, все отчеты, которые вы создаете в Power BI Desktop, публикуются на облачной платформе, известной как Power BI Service.

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

Архитектура Power BI Service состоит из двух частей:

  • фронтенд
  • бэкенд

Кластер фронтенд

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

Наряду с этим Azure Traffic Manager используется для направления пользовательских запросов в ближайший центр обработки данных после проверки подлинности. После проверки подлинности клиента/пользователя, Azure Content Delivery Network (CDN) распространяет статическое содержимое/файлы Power BI пользователям.

Кластер бэкенд

Сервисы Power BI на стороне сервера заботятся о визуализациях, наборах данных, хранилище, отчетах, подключениях к данным, обновлении данных и других взаимодействиях с Power BI. Для бэкенда веб-клиент имеет только две прямые точки взаимодействия – Azure API Management и Gateway Role. Эти два компонента отвечают за балансировку нагрузки, аутентификацию, авторизацию, маршрутизацию и т.д.

Работа Power BI Service

  • Power BI хранит свои данные в двух основных хранилищах: Аzure block storage и Azure SQL database. В блочном хранилище Azure содержатся наборы данных, загруженные пользователями, а все метаданные и системные данные хранятся в базе данных SQL Azure.
  • После того как Azure API Management аутентифицирует пользовательский запрос, он отправляет его в Gateway Role. Gateway Role обрабатывает запросы и направляет их к подходящим компонентам, таким как Presentation Role, Background Job Processing Role, Data Role и Data Movement Role.
  • Для примера, Presentation Role обрабатывает все связанные с визуализацией запросы, например, для информационных панелей и отчетов.
  • Для всех запросов, связанных с данными, Gateway Role отправляет запрос в Data Role или Data Movement Role.
  • Бэкенд Power BI Service использует Azure Service Bus для подключения локальных источников данных к облаку. Azure Service Bus получает все запросы на выборку данных из локального источника данных. Затем сервис обрабатывает заявку и выполняет запрос на локальном источнике данных для извлечения данных из него в облачную службу.
  • Azure Service Fabric управляет всеми микросервисами и компонентами, связанными с запуском Power BI.
  • Azure AD Cache помогает создавать отчеты в режиме реального времени, используя данные, хранящиеся в оперативной памяти системы Power BI.

Резюме

На этом мы завершаем наше краткое руководство по архитектуре Power BI. Здесь мы узнали обо всех важных компонентах архитектуры Power BI, увидели, как они работают совместно, а также узнали о функционировании Power BI Service и описали, как она работает.

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У компаний есть приложения, которые обрабатывают и хранят тысячи, даже миллионы транзакций каждый день. Возможность создавать, извлекать, обновлять и удалять эти данные стала реальностью благодаря базам данных, также называемым онлайн-системами обработки транзакций (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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 ваши потребности в доступности данных? Каковы ваши стратегии резервного копирования?

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

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

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

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

74 queries in 0,288 seconds
Website nonton bokep jepang