Этапы реализации проектов

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

Основные этапы

Этап 1. Разработка проектного решения

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

  • Общий анализ проекта. Формируются цели проекта, описываются основные вехи и ключевые показатели, объем работ и т.д.

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

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

  • Схема интеграции (опционально). Описание взаимодействия информационных систем, направления обмена данных, потоки и т.д.

Этап 2. Реализация проекта

Этап посвящен непосредственной работе с системой Юниверс MDM.

  • Роли пользователей и права доступа. Только что установленная система не содержит ничего, кроме учетной записи суперпользователя (администратора с максимально полными правами доступа). В качестве первых шагов рекомендуется создать роли и раздать ролям права доступа. Эта задача может выполняться в несколько шагов. Первым шагом может стать распределение прав доступа для ролей администраторов системы. Второй шаг: распределение прав доступа для операторов данных. Второй шаг рекомендуется выполнять после публикации финальной версии модели данных, так как распределение прав доступа на реестры/справочники возможно только при их наличии.

  • Учетные записи пользователей. Создание учетных записей и назначение им соответствующих ролей. По аналогии с ролями, рекомендуется выполнять в несколько шагов: сначала создать пользователей-администраторов, затем операторов данных.

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

  • Основные шаги наполнения модели:

    • Создание реестра/справочника. Задание основных свойств нового объекта, таких, как имя, тип, способ генерации внешнего ключа и т.д. Рекомендуется сначала создавать справочники, затем реестры. Причем, начинать следует с реестров, на которые ссылаются другие реестры.

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

    • Создание связей. Если реестры/справочники создавались в рекомендованной последовательности, то создание связей не потребует возврата к другим реестрам/справочникам и создания реестра/справочника специально под нужную связь. Также можно сначала создать все реестры/справочники, не заполняя вкладку "Связи", а затем в следующей итерации задать все связи.

    • Настройка консолидации. Задание веса каждому источнику данных, из которого приходят данные в реестр/справочник. Вес означает уровень доверия к источнику, и чем число выше, тем выше уровень. Системный источник данных (то есть, данные, созданные в системе) имеет значение 100. Вес должен быть не нулевым. Доступна настройка как для реестра/справочника в целом, так и для каждого атрибута по отдельности.

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

  • Модель данных: правила качества. Правила можно создавать как в процессе создания реестра/справочника, так и отдельно. Подробнее читайте Правила качества. Для редакции СЕ: правила валидации обрабатываются, но не отображаются в интерфейсе пользователя.

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

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

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

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

Правила качества

Настройку правил качества рекомендуется выполнять на первых этапах внедрения системы Юниверс MDM, одновременно с настройкой модели данных.

Предварительно:

  • Выполнена аналитика проекта переноса данных в систему Юниверс MDM: готово описание модели данных, функций обработки данных, правил качества и т.д.

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

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

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

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

Вы можете воспользоваться одним из подходов к созданию правил качества.

Подход 1:

  • Создается новый реестр/справочник. Настроены основные свойства.

  • Создаются атрибуты реестра/справочника.

  • Создаются правила качества для реестра/справочника.

  • Реестр/справочник сохраняется. Переход к следующему реестру/справочнику.

Подход 2:

  • Создается набор реестров/справочников, настраиваются свойства и атрибуты.

  • Опционально: модель данных может быть опубликована для тестирования.

  • Создается набор правил качества для каждого реестра/справочника.

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

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

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

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

Бизнес-процессы

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

Предварительно:

  • Созданы роли пользователей (либо определены логические имена будущих ролей).

Первый этап. Описание и подключение. На этом этапе создается два файла:

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

  • Вспомогательный Java-класс.

Файлы помещаются в каталоги системы Юниверс MDM, а также прописываются в конфигурации.

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

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

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