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

Оригинальное название: The Fat of Business Data

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

Типичные симптомы: показатели выручки, экспортируемые из ERP финансовым сектором, не совпадают с суммой подписанных денег из статистики CRM; дни оборота акций для команд цепочки поставок не соответствуют фактическим данным входа и входа в систему склада WMS; генеральный директор хочет увидеть «тенденцию ставок Māori по продуктовым линейкам за последние 12 месяцев», и ИТ-команды должны координировать три отдела, запускать пять отчетов и вручную консолидировать, прежде чем давать «предположительно возможную» цифру.

Это не проблема с данными. Это проблема.Данные, разбросанные по бизнес-системам «прибрежных», не имеют согласованных определений, стандартов и точек доступа.Сцены, описанные здесь, предназначены для предприятий с изолированными многосистемными данными, непоследовательной калибровкой отчетов и неэффективным анализом.ZhiHua TechМетодология построения данных и управления данными не представляет собой раскрытие данных для конкретных клиентов.

Типичные оперативные задачи

1.Разбросанные по нескольким системам данные, отсутствие единого глобального представления

• ERP контролирует финансовые ваучеры, CRM контролирует бизнес клиентов, WMS контролирует поток воды из запасов - модель данных трех систем независима друг от друга, с различными кодами, атрибутами и определениями статуса для одного и того же "клиента", "продукта" и "порядка" в их соответствующих системах.
• Руководство хочет видеть «Клиент 360» — какие продукты, история транзакций, записи жалоб, возвраты — ему нужно вручную извлекать данные из по крайней мере трех систем, а затем сталкивать их вместе, и процесс занимает время, и результаты склонны к ошибкам.
• Каждый бизнес поддерживает свои заявления Excel и запросы к базе данных отдельно, и один и тот же показатель (например, «ежемесячные продажи») может иметь пять различных цифр на компьютере пяти человек.

2. Качество данных неравномерно, а анализ не вызывает доверия

• Материал мастера данных "один размер кратный": тот же винт одного и того же поставщика, который представляет собой набор кодов в ERP, другой набор в WMS, и третий набор в R&D BOM. Это приводит к частым ошибкам в подсчетах запасов, сверках закупок и учете затрат.
• Повторяющиеся и противоречивые данные клиента: несколько записей (несколько разных имен и различных контактных данных) одного и того же клиента в CRM по историческим причинам, продажи не ясны о том, какая последняя версия и маркетинг может отправить одно и то же текстовое сообщение три раза одному и тому же клиенту.
• Недостающие данные и ненормальные значения: ключевые поля (например, суммы контрактов, даты поставки) пусты или явно ненормальны (дата 1970-01-01), но нет автоматического механизма обнаружения и восстановления качества и грязного потока данных в аналитические отчеты.

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

• Бизнес-анализ основан на головоломках Excel от двоюродных братьев, которые появились три недели назад. Конкурирующие стороны скорректировали свои стратегии ценообразования на данные в режиме реального времени и ждут результатов.
• Когда бизнес задает поисковый вопрос – «Каков показатель выкупа новых клиентов за последние три месяца?» – аналитики данных тратят полдня на написание SQL, калибровку и получение результатов.
• Отсутствие возможности анализа самопомощи: операторы не могут перетаскивать данные для самого поискового анализа, и все потребности в данных стоят в очереди в списке работы ИТ-сектора, создавая типичный «эффект узких мест» данных.

ZhiHua Tech Data Media Construction Методология построения медиа

Инвентаризация активов данных и управление основными данными

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

• Глобальный каталог активов данныхОбъединение данных, полей данных, частоты обновления данных и данных для всех бизнес-систем и Владельца для формирования карт данных на уровне предприятия. Этот шаг решает вопрос о том, где находятся данные.
• Главная Стандартизация данныхУстанавливает правила кодирования на уровне предприятия, спецификации атрибутов и процессы обслуживания вокруг основных субъектов данных, таких как материалы, клиенты, поставщики, организации, учетные записи.
• Базовый уровень качества данныхКоличественные показатели (полнота, уникальность, согласованность, своевременность, точность), определяющие качество данных, полное сканирование существующих данных, выявление наиболее важных панелей качества и разработка планов управления.

2. Формирование наборов данных и моделирование стратификации

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

• Слой набора данных (ODS)Синхронизирует исходные данные из бизнес-систем в среду данных в режиме реального времени через CCDC (сбор данных об изменении), канал ETL / ELT и API. Сохраняйте полную схему исходных данных, необработанных и обеспечивайте отслеживаемость данных.
• Уровень хранилища данных (DW)Используя методологию моделирования размеров Kimball или DataVault, которая очищает, стандартизирует, связывает необработанные данные и создает аналитически ориентированные тематические модели доменов - темы продаж, темы закупок, темы инвентаризации, финансовые темы, человеческие темы и т. Д. Этот уровень является «единственным источником достоверных данных».
• Наборы данных (DM)Для конкретных бизнес-сценариев (управленческая кабина, анализ воронки продаж, анализ производительности цепочки поставок, изображение клиента) создайте широкоформатный и индикаторный вид предварительно агрегированного, что позволит бизнес-участникам получить необходимый анализ при минимальной сложности SQL.
• Управление калибровкой индикаторовСоздать словарь показателей предприятия – каждый показатель (например, GMV, Māori, дни оборота акций, показатели удержания клиентов) имеет одно имя, калибровку, источник данных и ответственное лицо.При цитировании в любом заявлении индекс берется из словаря показателей, устраняя проблему «неуказанных чисел» вообще.

3. Услуги по самообслуживанию и анализу данных

Ценность центра обработки данных в конечном итоге отражается в том, чтобы «сделать данные доступными для тех, кто в них нуждается»:

• Платформа BI для самопомощиОператоры подключаются непосредственно к муниципальному уровню набора данных с помощью инструментов перетаскивания BI (например, Metabase, Superset или Power BI), создают самогенерируемые отчеты и панели без ИТ-вмешательства в написании SQL. ИТ-команды перешли от «выборщика данных» к «носителям платформы данных».
• Данные APIВнешняя экспозиция активов данных в среднем канале через REST API для фронт-энд приложений, мобильного концевого и малого потребления программ. Например, система CRM может осуществлять поиск данных изображения клиента 360 в режиме реального времени, а не поддерживать копию клиента, срок действия которой может истекать локально.
• Анализ крови и воздействияЗапись полного потока данных (кровной линии) из таблицы источников в конец каждого отчета. Когда поле таблицы изменяется вверх по течению, все зависимые стороны вниз по течению автоматически информируются, избегая «поездки вверх по течению, не зная, кто его использует»

Ключевые технические компоненты

Доставляемые

Предполагаемая ориентация на ценность

• Один номер, один калибр.Определение, источник и логика расчета основного показателя эффективности предприятия управляются централизованно на среднем этапе, а цифры, которые руководство видит в любом отчете и на любом экране, получены из тех же данных.
• От «Т+7» до «Т+0».Цикл обновления бизнес-данных вручную агрегируется от недели / месяца до часа или минут для автоматической синхронизации, и лица, принимающие решения, могут видеть и реагировать на сигналы данных в день проблемы.
• Выводит производительностьОперации выполняют 80% своих ежедневных потребностей по самопомощи BI, и ИТ-команды сосредоточены на создании платформ данных и улучшении качества данных, а не на том, чтобы устали от выполнения ряда рабочих заказов.
• Установите базу данных для AI.Высококачественные, хорошо управляемые бизнес-данные являются предпосылками для реализации AI. После завершения среды данных AI RAG может напрямую подключаться к чистым источникам данных, что значительно сокращает цикл подготовки для проектов AI.