Методология анализа данных

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

data-knowledge-solutions

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

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

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

analysis-levels

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

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

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

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

analysis-bi-stages3

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

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

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

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

bi-areas

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

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

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

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

analysis-steps

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

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

logistics-processes-cycle

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

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

process-unit-function-indicator

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

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

dwh-star

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

indicator-levels3

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

Пример из логистики

Для примера возьмем пример из логистики (Supply Chains).

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

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

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

how-much-to-order

На рисунке показан набор факторов, влияющих на решение «Сколько заказать товара у поставщика?» как из области самой логистики, так и из финансовой и маркетинговой областях.

С точки зрения продавца решение «Увеличить объем продаж» позволяет обеспечить наличие товара на складе и ускорить выполнение заказов покупателей. Это также является важным фактором конкурентоспособности.

increase-order-quantity

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

decrease-order-quantity

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

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

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

logistics-indicators-demo

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

Таким образом. показатель «Бюджет по складу» является управленческим, поскольку он связан с принятием решений и обеспечивает баланс между продажами, складом и финансовыми ресурсами.

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

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

Для обратной связи нам потребуется разработать новые или использовать существующие как контрольные показатели:

  • Количество заказов, невыполненных из-за отсутствия товаров на складе — позволяет оценить спрос и увеличить закупки соответствующих товаров;
  • Просрочка (Количество неликвидных товаров) — замороженные финансовые средства из-за отсутствия спроса.

Органайзер аналитика

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

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

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

Аналитик разрабатывает требования на основе этих знаний также в формализованном формате (методология формализации требований). Это обеспечивает высокое качество требований и трассировку изменений.
bi-organizer

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

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