Что такое внедрение данных
Data Driven-подход
Data Driven-подход — это способ принимать управленческие решения, основываясь на больших данных. Его используют для построения бизнес-модели или маркетинговой стратегии, при составлении плана продаж, в программировании и даже в дизайне.
Для каждой сферы выбирают конкретный тип информации, например данные о покупках, геолокации мобильных устройств, количестве поисковых запросов по теме. При поиске помещения под новую кофейню владелец может проанализировать трафик людей на улицах и выбрать место с наибольшей проходимостью.
Полное название этого подхода — Data Driven Decision Making (DDDM), то есть информационно обоснованные решения (или data driven decisions). Он стал альтернативой устаревшему подходу HiPPO (Highest Paid Person’s Opinion) — принятию решений на основе мнения руководства. Проблема этого подхода в том, что руководитель или менеджер не могут быть объективными и компетентными во всех вопросах и знать все особенности аудитории.
Melbourne Business School проводила исследование того, как компании в 46 странах используют аналитику, и выяснилось, что только 6% из них могут считаться лидерами в этом направлении. Это тот бизнес, в котором проработана аналитическая стратегия и в нее включены все подразделения, высший менеджмент принимает решения исключительно на основе данных, а также в реальном времени мониторится ситуация на рынке.
Еще 49% компаний отнесли к категории «Исследователи», так как они частично используют данные для принятия решений, но не до конца развили инфраструктуру для полноценного Data Driven. Остальные компании отнесли к «Подражателям» и «Отстающим», так как они используют данные только в одной конкретной области или не развивают аналитику вообще.
Data Driven-подход полезен на разных этапах развития:
Например, агентство RUSFAIR GROUP проводит исследования для запуска новых продуктов на рынке электронной коммерции в Китае. Они делают анализ инфополя бренда и конкурентов, затем — анализ потенциальных площадок, исследование аудитории в WeChat — самом популярном социальном приложении в Китае, Douyin — китайском аналоге TikTok и других социальных сетях. Такие исследования позволяют определить объем необходимых инвестиций и грамотно выбрать площадки для продвижения.
Фитнес-клуб в Перми через 7 месяцев после открытия поставил перед собой задачу выйти в лидеры рынка. Для доработки продающей концепции маркетологи изучили опыт конкурентов в городе, собрали данные о том, почему люди не ходят в фитнес-клубы, что их удерживает и почему бросают занятия. В результате изменений, основанных на данных, клуб увеличил выручку в два раза.
Альфа Банк в прошлом году проанализировал всю воронку продаж и поведение клиентов, которые в итоге подали заявку на карту и получили ее на руки. На основе этих данных рекламу стали таргетировать на пользователей, которые с наибольшей вероятностью заинтересуются продуктом, благодаря чему число заявок выросло в 1,6 раза.
Решения на основе данных
Для использования Data Driven-подхода требуются навыки работы с аналитикой. Во-первых, нужно уметь считывать данные из таблиц, графиков и диаграмм, потому что иначе даже на основе самых верных данных можно сделать неверные выводы. Во-вторых, нужно критически относиться к самим данным и задавать аналитику правильные вопросы:
Управление на основе данных включает в себя три подготовительных шага:
Недостатки Data Driven-подхода
Как стать Data Driven-компанией
Data Driven-организация корректно собирает, проверяет и обрабатывает данные и использует их на пользу бизнеса. Такие компании имеют отлаженный механизм работы с данными, в котором все сотрудники четко понимают задачи: data-аналитик собирает данные, отдел маркетинга умеет ставить четкое ТЗ на сбор конкретной информации, а руководство соотносит это с бизнес-целью.
Мария Михеева, продуктовый аналитик AliExpress, считает, что организация Data Driven-подхода затрагивает такие аспекты работы компании, как миссия, идеология и обучение сотрудников. Но в основе подхода все-таки лежат качественные данные — достоверные и очищенные от лишней информации, ненужной компании. На этих данных как раз выстраивается data-менеджмент. Кроме них, есть другие важные аспекты:
Главный критерий успеха в Data Driven-подходе — понимание сотрудниками компании того, зачем нужны данные. Поэтому работу над этой управленческой стратегией стоит начинать с внутреннего PR, презентации и обучения.
В каких профессиях используется Data Driven-подход
Менеджмент
Управление на основе данных — одна из причин роста компаний. Оно помогает оптимизировать расходы, повысить клиентоориентированность, отслеживать изменения на рынке и, как результат, увеличить прибыль. Пока полноценно такой подход реализуют только крупные игроки уровня Google, так как внедрение культуры Data Driven в компании — это ресурсозатратный процесс, который не всем по карману.
Маркетинг
Data Driven-маркетинг позволяет продвигать продукт на ту аудиторию, которой он интересен, что значительно сокращает рекламные расходы. Этим инструментом пользуются, например, маркетплейсы, которые собирают информацию об истории поиска своих клиентов, их покупках и интересах, чтобы предлагать им нужные категории товаров.
Веб-разработка
Разработчики опираются на данные взаимодействия пользователей и сервиса, чтобы зацепить и удержать пользователя. Например, в одной из компаний исследовали, как внутри приложения влияет на вовлечение пользователей лента, предлагающая контент на основе машинного обучения.
Кейсы компаний, которые реализуют Data Driven-подход
Управление
Управление на основе данных позволило компании «Сибур» перестроить работу отделов и избавиться от принципа «глубокого колодца», когда специалисты имеют доступ только к информации, необходимой для выполнения их обязанностей. Автоматизация отделов происходила разрозненно, большой пласт информации скрывали, мотивируя это коммерческой тайной, поэтому у менеджмента разных сегментов было недостаточно данных для анализа работы предприятия.
Внедрение Data Driven-подхода позволило открыть доступ к 80% ранее скрытой информации, сотрудники начали самостоятельно проверять гипотезы на данных, составлять интерактивные дашборды. С помощью бизнес-симуляторов компания начала моделировать различные ситуации на рынке и рассчитывать целесообразность инвестиций или запуска новых продуктов.
Разработка маркетинговых продуктов
На туристическом рынке технологию Data Driven используют, чтобы продвигать путешествия на ту аудиторию, у которой есть интерес к направлению, а также отслеживать реальную эффективность рекламы. Например, если человек интересовался турами в Испанию, смотрел билеты или отели, то он обязательно увидит таргетированную рекламу.
Анализ аудитории
Сбербанк уже несколько лет использует Data Driven для анализа поведения заемщиков. Интерактивная анкета, которую использует банк для сбора информации, позволяет выявить один из важных психологических параметров — уравновешенность или импульсивность клиента. Для банка это важно, так как рассудительные люди являются более добросовестными заемщиками, чем импульсивные. Вопросы в анкете для заемщиков помогают определить уровень финансовой грамотности, их стабильность, опыт работы и трезвое восприятие своего финансового положения.
Получите реальные знание и навыки, необходимые для работы. Обучение на основе практики и помощь в трудоустройстве. Скидка 45% по промокоду BLOG.
Понятие внедрения и связывания объектов
Связанный объект – это данные (объект), созданные в одном файле и вставленные в другой файл с поддержкой связи между файлами. Связанный объект может обновляться одновременно с обновлением исходного файла. Связанный объект не является частью файла, в который он вставлен.
Внедренный объект – это данные (объект), вставленные в файл. Внедренный объект становится частью файла. При двойном щелчке внедренный объект открывается с помощью программы, в которой был создан.
Составной (интегрированный) документ – документ, в котором объединены данные разного типа, созданные в разных приложениях.
В большинстве случаев в составном документе можно выделить главную часть, которая создавалась в одном приложении и куда вставлялись объекты из других приложений.
Составной документ вызывается из приложения, где создавалась его главная часть.
Следует заметить, что возможно создание составного документа, у которого нет главной части и который весь состоит из объектов, созданных в других приложениях.
Когда в некотором приложении используется команда «Вставить» (Paste), то создается внедренный компонент (embedded component) или некоторая совокупность внедренных данных (embedded item). Эти внедренные данные сохраняются как часть документа, который их содержит. В этом случае, к примеру, файл текстового процессора вроде Microsoft Word может содержать не только текст, но и изображения, графики, формулы или какие-либо иные типы данных.
Технология OLE предоставляет иной способ включения данных, созданных другими приложениями: создание связанного компонента (linked component), который называют также связанными данными (linked item) или просто связью (link). Алгоритм связывания данных подобен алгоритму их внедрения за тем исключением, что используется команда вставить связь (Paste Link) вместо вставить. В отличие от внедренного компонента, связанный компонент хранит путь путь к оригинальным данным, которые, как правило, сохраняются в отдельном файле.
Например, когда в документе Microsoft Word создается связь к некоторым ячейкам таблицы Microsoft Excel, то табличные данные сохраняются в документе (файле) Excel. Таким образом, документ Word содержит только ссылку на оригинальный документ Excel. Теперь при двойном щелчке по ячейкам вставленной в текст таблицы запускается приложение Excel и загружается файл, содержащий эти табличные данные.
Любые данные, внедрены ли они или связаны. имеют тип, ассоциированный с породившим их приложением. Это приложение, тем не менее, может создавать более чем один тип данных. К примеру, то же приложение Excel может создавать листы, диаграммы и макролисты (macrosheet). Каждый из этих видов данных однозначно идентифицируется CLSID (идентификатором класса).
Серверы и контейнеры.
Технология OLE предполагает, в первую очередь, наличие двух приложений: приложение-сервер и приложение-контейнер. Приложение сервер всегда обрабатывает внедренный (embedding) или связанный (embedding) OLE-документ.
Приложением-контейнером называют такое приложение, которое может включать внедренный или связанные данные в свои собственные документы. Документы, обрабатываемые приложением-контейнером, должны сохранять и отображать OLE-документы точно так же, как и свои собственные данные, т.е. данные, созданные приложением-контейнером. Кроме того приложение-контейнер должно позволять пользователям вставлять новые данные или редактировать существующие путем активизации приложения-сервера.
Приложением-сервером или приложением-компонентом называют такое приложение, которое может создавать OLE-документы для их последующего использования приложением-контейнером. Приложения-серверы обычно поддерживают технологию перетаскивания (drag and drop) или копируют свои данные в буфео обмена (clipboard), благодаря чему приложение-контейнер может вставить эти данные (в свой документ) как внедренные (embedding) или связанные (embedding). Любое приложение может быть и сервером и контейнером.
Приложения-серверы могут быть полными серверами или мини-серверами. Большинство приложений-серверов являются самостоятельными (stand-alone) приложениями или полными серверами (full-server). Такие серверы могут выполняться как самостоятельные приложения или могут быть запущены на выполнение приложениями-контейнерами. Мини-серверы могут быть запущены на выполнение только приложениями-контейнерами. т.е. не могут выполняться как самостоятельные приложения. Примерами мини-серверов служат Microsoft Draw и Microsoft Graph.
Контейнеры и серверы не взаимодействуют непосредственно, напрямую, а делают это посредством использования динамически подключаемых OLE-библиотек. Эти библиотеки предоставляют функции, которые вызывают контейнеры и серверы. В свою очередь контейнеры и серверы предоставляют функции обратного вызова (callback functions), которые вызваются OLE-библиотеками. Таким образом, OLE-библиотеки выполняют роль промежуточного слоя, разделяющего объединяющего контейнеры и серверы.
Благодаря такой технологии взаимодействия контейнер не должен знать деталей реализации сервера, что позволяет контейнеру получать данные, созданные любым сервером, и при этом не возникает необходимости в определении типа сервера, с которым взаимодействует контейнер. Вследствие этого пользователь приложения-контейнера может воспользоваться преимуществами будущих приложений и форматов данных. До тех пор пока эти новые приложения будут оставаться OLE-компонентами, составной документ (compound document) будет в состоянии включать данные, созданные такими приложениями.
Приложение-контейнер – это приложение, которое имеет специальный компонент, который, собственно, и называется контейнером. Компонент контейнер используется для того, чтобы хранить данные внедренного или связанного объекта (OLE-документа) и выполнять некоторые операции над объектом.
Для внедрения в приложение объекта необходимо использовать так называемый OLE-контейнер, правила создания и использования которого регламентированы СОМ. Также в соответствии со спецификацией СОМ должна быть обеспечена активизация объекта по месту (in-place activation), т.е. возможность редактирования объекта, находящегося в контейнере, с помощью соответствующего СОМ-сервера
Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет
Основы внедрения зависимостей
В этой статье я расскажу об основах внедрения зависимостей (англ. Dependency Injection, DI) простым языком, а также расскажу о причинах использования этого подхода. Эта статья предназначена для тех, кто не знает, что такое внедрение зависимостей, или сомневается в необходимости использования этого приёма. Итак, начнём.
Что такое зависимость?
Прежде чем продолжить, я хочу уточнить, что такая взаимосвязь — это хорошо, ведь нам не нужно, чтобы один класс выполнял всю работу в приложении. Нам необходимо разделять логику на разные классы, каждый из которых будет отвечать за определенную функцию. И в таком случае классы смогут эффективно взаимодействовать.
Как работать с зависимостями?
Давайте рассмотрим три способа, которые используются для выполнения задач по внедрению зависимостей:
Первый способ: создавать зависимости в зависимом классе
Проще говоря, мы можем создавать объекты всякий раз, когда они нам нужны. Посмотрите на следующий пример:
Это очень просто! Мы создаем класс, когда нам это необходимо.
Преимущества
Недостатки
Каждый класс должен выполнять лишь свою работу.
Поэтому мы не хотим, чтобы классы отвечали за что-либо, кроме своих собственных задач. Внедрение зависимостей при этом является дополнительной задачей, которую мы ставим перед ними.
Второй способ: внедрять зависимости через пользовательский класс
Итак, понимая, что внедрение зависимостей внутри зависимого класса — не самая лучшая идея, давайте изучим альтернативный способ. Здесь зависимый класс определяет все необходимые ему зависимости внутри конструктора и позволяет пользовательскому классу предоставлять их. Является ли такой способ решением нашей проблемы? Узнаем немного позже.
Посмотрите на пример кода ниже:
Преимущества
Недостатки
Второй способ очевидно работает лучше первого, но у него всё ещё есть свои недостатки. Возможно ли найти более подходящее решение? Прежде чем рассмотреть третий способ, давайте сначала поговорим о самом понятии внедрения зависимостей.
Что такое внедрение зависимостей?
Внедрение зависимостей — это способ обработки зависимостей вне зависимого класса, когда зависимому классу не нужно ничего делать.
Исходя из этого определения, наше первое решение явно не использует идею внедрения зависимостей, а второй способ заключается в том, что зависимый класс ничего не делает для предоставления зависимостей. Но мы все ещё считаем второе решение плохим. ПОЧЕМУ?!
Поскольку определение внедрения зависимости ничего не говорит о том, где должна происходить работа с зависимостями (кроме как вне зависимого класса), разработчик должен выбрать подходящее место для внедрения зависимостей. Как видно из второго примера, пользовательский класс является не совсем правильным местом.
Как же сделать лучше? Давайте рассмотрим третий способ обработки зависимостей.
Третий способ: пусть кто-нибудь ещё обрабатывает зависимости вместо нас
Согласно первому подходу зависимые классы отвечают за получение своих собственных зависимостей, а во втором подходе мы переместили обработку зависимостей из зависимого класса в пользовательский класс. Давайте представим, что существует кто-то другой, кто мог бы обрабатывать зависимости, вследствие чего ни зависимый, ни пользовательский классы не выполняли бы эту работу. Этот способ позволяет работать с зависимостями в приложении напрямую.
«Чистая» реализация внедрения зависимостей (по моему личному мнению)
Ответственность за обработку зависимостей возлагается на третью сторону, поэтому ни одна часть приложения не будет с ними взаимодействовать.
Внедрение зависимостей — это не технология, фреймворк, библиотека или что-то подобное. Это просто идея. Идея работать с зависимостями вне зависимого класса (желательно в специально выделенной части). Вы можете применять данную идею, не используя какие-либо библиотеки или фреймворки. Тем не менее, мы обычно обращаемся к фреймворкам для внедрения зависимостей, потому что это упрощает работу и позволяет избежать написания шаблонного кода.
Любой фреймворк внедрения зависимостей имеет две неотъемлемые характеристики. Вам могут быть доступны и другие дополнительные функции, но эти две функции будут присутствовать всегда:
Во-вторых, фреймворки позволяют определить, как нужно предоставить каждую зависимость, и это происходит в отдельном файле (файлах). Приблизительно это выглядит так (учитывайте, что это лишь пример, и он может отличаться от фреймворка к фреймворку):
Преимущества
Обратите внимание, никакой код внутри приложения не меняется, только метод провайдера. Кажется, что ничего не может быть ещё проще и гибче.
Недостатки
Заключение
В этой статье я попытался объяснить основы работы с понятием внедрения зависимостей, а также перечислил причины необходимости использования этой идеи. Существует ещё множество ресурсов, которые вы можете изучить, чтобы больше узнать о применении DI в ваших собственных приложениях. Например, этой теме посвящён отдельный раздел в продвинутой части нашего курса Android-профессии.
Что такое Мастер-Данные и зачем они нужны
Введение
(клик по картинке ведёт внутрь публикации)
Развиваясь, организации внедряют всё больше и больше информационных систем совершенно различных направлений: бухгалтерский учет, управление персоналом, управление складом etc. Системы живут и развиваются независимо друг от друга до того самого момента, как компании не потребуется взглянуть на свои данные целиком. Объемы данных уже достигают критической точки и выясняется, что сопоставить и сравнить данные вручную становится просто невозможно. Решения основанные на противоречивых и невыверенных данных ведут к управленческим ошибкам, а дубли и неактуальность данных к неверным бизнес решениям.
Конечно же проблема описанная выше не нова и сегодня мы обсудим классический способ решения — систему управления мастер-данными.
Что такое MDM
Master Data Management (сокращенно: MDM, МДМ, НСИ; варианты перевода: управление мастер-данными, нормативно-справочная информация) система — комплекс процессов, систем управления, стандартов и программ позволяющих единообразно работать с данными. Проще говоря, МДМ-система предоставляет целостный взгляд на все составляющие бизнеса, в том числе на источники данных, авторство, качество, полноту и на потенциальное использование данных. (Подробнее: Задачи управления мастер-данными)
(кликабельно)
Типы корпоративных данных: что такое справочные и транзакционные данные
Чтобы разобраться, чем являются и не являются мастер-данные разберем основные типы корпоративных данных.
(взято отсюда)
Неструктурированные данные — текст, почта, и другие данные, у которых нет формально определенной и описанной структуры.
Полуструктурированные — данные не имеющие определенной схемы (или имеющие переменную структуру), но тем не менее имеющие формальное описание в виде тегов и\или определенных маркеров. XML — пример, полуструктурированных данных.
Структурированные (транзакционные) данные — данные имеющие формально определенную схему.
Метаданные — это данные описывающие другие данные, например, схема базы данных клиентов, конфигурационный файл или шаблон отчета.
Мастер-данные — это данные, содержащие ключевую информацию о бизнесе, в том числе о клиентах, о продуктах, о работниках, о технологиях и материалах. Каждая из этих групп может разделяться на несколько предметных областей: в категорию люди входят клиент, продавец, поставщик. Так же может иметь набор правил валидации, которым должны удовлетворять данные.
Иногда в отдельную категорию выделяют иерархические данные — это данные, в которых хранятся отношения и взаимодействия между данными. Подробнее.
Пример, общей структуры мастер-данных и валидационных правил (кликабельно)
Зачем оно нужно?
Исторически многие системы хранения, анализа и визуализации данных развивались параллельно и не совместимы между собой. По мере роста компании интеграция данных становится всё более важной и во многих случаях критической задачей, согласно Microsoft уже компании среднего размера ощущают на себе последствия работы с разнородными данными.
Таким образом одной из задач МДМ-систем является синхронизация данных, что упрощает решение сопутствующих задач, как подготовка финансовой отчетности.
МДМ-система — это один из краеугольных камней в архитектуре бизнеса вместе с ERP и BI системами, позволяющий системам аналитики и ведения бизнеса иметь единое преставление о данных, независимо от источника и формы.
Рассмотрим несколько классических случаев, где необходимо использовать и внедрять систему управления мастер-данными.
Зоопарк ИТ-систем и консолидированная отчетность
Пусть в компании больше трех систем хранения-анализа данных. Заполняются они и развиваются независимо друг от друга. В какой-то момент появляется необходимость собрать консолидированную отчетность и необходимо синхронизировать нормативно-справочную информацию. Например, существуют компания Ромашка с оборотом в 1М и имеются две записи «Общ.огр. Ромашка» и «ООО Ромашка» в разных системах с оборотом 400к и 600к, без инструментов синхронизации, система создания отчетности не сумеет объединить записи.
Интеграция систем
Пусть имеется несколько 1С систем в отделениях компании и счета, выставленные ООО «Ромашка» необходимо выгрузить и проанализировать в CRM. Если в CRM заведены несколько дублей, например Ромашка и Общ. Огр. Ромашка, то встает вопрос к какой Ромашке в CRM эти счета привязать и есть ли среди этих Ромашек нужная?
Единая база контрагентов
Прежде всего создание единой базы необходимо, для качественной и достоверной информацию о контрагентах. Если клиент, уже подписавший контракт, получает дополнительные N звонков о необходимости выслать уже отправленные документы (т.к. «Общ.огр. Ромашка» и «ООО Ромашка» — синтаксически разные компании), то это негативно отражается на отношениях компании.
Очистка и нормализации данных
Описанные выше случаи — это задачи по очистке и нормализации данных (data cleaning and data quality).
Очистка и нормализация данных — это безусловно инструменты, цель — это повышение лояльности клиента (e.g. избегаем повторных звонков), создание отчетности (уверенность в корректности аналитики) и увеличение скорости выполнения задач (быстрее проходим цикл продаж).
Как правило, клиент приходит к необходимости внедрения системы управления НСИ. Например необходимость оперативного контроля над деятельностью предприятия может потребовать сбора консолидированной отчетности, что в свою очередь приведет к необходимости синхронизации НСИ в ИТ-система, что в свою очередь потребует внедрения системы управления НСИ.
Случаи из жизни
Четырнадцать 1С-ок
У одной компании N было четырнадцать 1С систем в филиалах и вот однажды им пришлось срочно предоставить отчетность о своей деятельности в какую-то там палату. Отсутствие единой отчетности грозило существенными проблемами и вот M сотрудников несколько недель вместе сводили и выверяли данные. А могли бы просто физически не успеть.
Клиент из Астрахани отправил фуры заказчику в другой регион, а обеспечение в пути оказывала компания Х, у которой не было МДМ-системы и единой базы контрагентов. Во время путешествия фуры проходили обслуживание в двух регионах — и по окончанию поездки компания Х выставила счет клиенту по этим регионам по стандартному прейскуранту без положенной скидки за объем, так как клиент был записан в этих двух регионах под чуть-чуть по-разному и система не сопоставила имена. Итог — дополнительные разбирательства и ухудшение деловых отношений.
Повторные звонки
Однажды клиенту позвонили шесть (!) раз после того, как контракт был подписан. Из-за подобной некомпетентности лояльность клиента и контракт были под угрозой.
Методы решения
Рассмотрим два наиболее популярных метода решения проблем, описанных выше.
Административное решение
Административный подход — сначала вычистить уже имеющиеся дубли в ИТ-системах, разработать систему кодировок, по которым можно сопоставить записи в справочниках разных ИТ-систем, и регламенты. Такой метод относительно прост, но имеет ряд недостатков – он не предотвратит рассинхронизацию НСИ в разных системах, а регламенты всегда можно обойти.
Внедрение MDM-системы
Технологический подход — использование системы обеспечивающей синхронизацию и единое представление данных. Как правило большинство крупных компаний внедряют различные версии MDM, когда ручная консолидация справочной информации и отчетности становится невозможной, а внедрение любой новой системы вынуждает изменять регламент и кодировки, только усиливая хаос.
Безусловно, единовременное введение МДМ-системы не решит все проблемы и по мере развития бизнеса, должна развиваться и МДМ-система, может даже измениться и сам тип МДМ системы (основные типы освещены ниже), однако, как показывает практика MDM является оптимальным бизнес решением в подобных случаях.
Типы МДМ-систем
Мы рассмотрим три основных типа MDM-систем — подробнее можно прочитать тут.
Централизованная система
Выбирается одна IT система, это может быть как уже имеющаяся IT-система, так и отдельная система управления НСИ. Справочные данные в этой системе будут считаться эталонными, вестись в ней и рассылаться в другие системы. При этом создание и редактирование справочных данных в других IT системах запрещается. Преимуществами такого подхода являются:
Аналитическая система
В аналитической системе НСИ все элементы НСИ создаются в клиентских системах, откуда отправляются в систему НСИ, где из этих элементов формируется запись справочника НСИ. Это позволяет быстро внедрять систему, внося минимальные изменения в клиентские системы.
Но так как НСИ в отдельно взятой IT-системе ни с чем не синхронизируется, то в самой IT-системе могут быть дубли и отчетность может расплыться, поэтому построение оперативной отчетности затруднено (про локальную отчетность также говорят, что она «грязная» — локальные записи НСИ могут не соответствовать записям в системе НСИ).
Гармонизированная система
Эта система вобрала в себя лучшее из централизованной и аналитической систем. Она позволяет заводить данные в IT-системах, и затем сопоставлять с уже заведенными, умеет искать потенциальные дубли, разрешать конфликты, связанные с одновременным изменением одних и тех же данных в разных IT-системах, синхронизировать НСИ в IT-системах. Таким образом не меняются и не нарушаются бизнес-процессы, минимизируются ручная работа по подготовке отчетности — то есть просто строиться локальная отчетность. Однако данные подход является наиболее дорогим, трудоёмким и требуют серьезной экспертизы для построения, а так же может потребовать модификации клиентских приложений.
Примеры реализации MDM-систем
Примером аналитической системы управления НСИ является Navicon SalesOut, а примером централизованной и гармонизированной – разные конфигурации Navicon MDM.
Индикаторы необходимости внедрения МДМ-систем
Ключевые: необходима интеграция различных систем и единая отчетность на основе этих данных.
Частные предпосылки внедрения на примере с одним из клиентов