Уважаемые коллеги, всем доброго дня. 

В данной статье хочу поделиться собственным опытом знакомства с MDM решением компании Юнидата (UniData). Попытаюсь сделать акцент на конкретные трудности и особенности платформы, с которыми столкнулся при переходе с SAP MDM на ЮниДата MDM.

Предыстория проекта

К моменту старта проекта по переходу на UniData MDM в Компании уже примерно 5 лет функционировала корпоративная система управления нормативно-справочной информацией (КСУ НСИ) на базе SAP MDM. Проект внедрения SAP MDM был по-настоящему успешным и эксплуатация системы практически не создавала проблем.

В КСУ НСИ велись два общекорпоративных справочника:

•  материально-технических ресурсов, работ и услуг (МТРиУ), 200000 записей

•  контрагентов, 40000 записей

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

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

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

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

В силу разных причин перед Компанией встала задача импортозамещения системы SAP MDM с полным сохранением существующей функциональности.

В рассмотрение брались все самые распространенные отечественные решения, из которых, в силу различных причин, отсеялись все, кроме Unidata MDM.

В пользу Unidata сыграл западный опыт (в дальнейшем авторитетное международное аналитическое агентство Gartner даже включило Unidata в свой "Магический квадрант"), универсальность решения (рассматривались и смежные проекты внедрения MDM под другие данные с иными моделями ведения), основа технологического стека на свободном ПО с открытым исходным кодом и лицензионная политика, в которой метрикой выступило количество справочников.

Перейду к конкретике, все дальнейшее сравнение и ожидания от функциональности платформы будут опираться на решение SAP MDM. Условно разделю выявленные проблемы на 3 блока:

Архитектурные особенности и базовая функциональность

• Отсутствие понятия "легитимное состояние записи".

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

  

• Ведение классификаторов без бизнес-процесса как часть модели данных.

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

• Изначально одним из плюсов платформы нам виделась работа с данными в одном интерфейсе (в отличие от SAP MDM, где данные велись в 2 интерфейсах - "тонком" и "толстом" клиентах), как выяснилось от чего хотели уйти к тому и вернулись.

  

• Множественная классификация.

  В системе безальтернативно реализована модель данных, предусматривающая множественную классификацию, при которой одной записи можно присвоить несколько классов одного классификатора. Как правило, для большинства справочников МТР множественная классификация не допускается на уровне методологии.
  Следствием такой реализации является отсутствие понятия "переклассификация" при использовании стандартной пакетной операции загрузки или пакетной модификации в интерфейсе (update) существующих записей справочника. Если вместо указанного класса привести ссылку на другой класс, то существующий класс при загрузке и модификации в интерфейсе не заменяется, а добавляется как второй. 

  

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

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

• Правила качества нельзя задавать на шаги бизнес-процесса.

  В платформе есть достаточно мощный инструментарий - правила качества (ПК), который позволяет задавать всевозможные правила валидации, проверки и обогащения данных. При этом архитектурой платформы не предусмотрена возможность задавать ПК на шаг бизнес-процесса, такую задачу можно решить только трудоемкой разработкой (в кастомизационной части кода). На простых формализованных справочниках такой подход приемлем, но на более сложных справочниках, таких как справочник МТР, требовать от пользователя знания тонкостей ведения данных на мой взгляд некорректно, для этого и существует специализированная служба НСИ.
  При этом важно отметить, что данный подход еще и не позволяет реализовывать понятие "Черновик" заявки как запись с любым уровнем заполнения атрибутов, при попытке сохранить заявку в стадии "черновик" пользователь должен заполнить все обязательные данные и пройти все проверки и валидации.

  

• Не задаются ограничения длины строки на атрибуты (поля).

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

  

• Нет настроек для создания типовых предустановленных фильтров, отражающих срезы для работы с заявками.В платформе отсутствует возможность создавать и задавать настройками в модели данных для разных ролей фильтры, отражающие типовые срезы для работы с заявками. Например, ответственному за распределение заявок в работу экспертам необходимо видеть все поступившие, но не распределенные заявки, инициатору заявок необходимо видеть заявки, которые вернулись ему для устранения замечаний, эксперту все заявки, находящиеся у него в работе и т.д.
  Данный инструментарий реализован во всех зрелых MDM-решениях, нужен для стандартизации и упорядочения процесса обработки заявок, снимает много вопросов со стороны пользователей и позволяет гибко реагировать на изменения в BPM. В рамках нашего проекта платформа была доработана и сущность "Предустановленный фильтр" была впервые введена, однако настроек по отдельным ролям для него нет, то есть пользователи видят все предустановленные фильтры, даже если для них они не предназначены, а сама разработка одного предустановленного фильтра не относится к настройке системы, тарифицируется в более чем в 10 человеко-дней.

  

• Персональные настройки хранятся в кэше браузера.

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

• Отсутствует развитой инструментарий выгрузки и загрузки данных.

• В платформе не предусмотрены развитые штатные средства для пользовательской выгрузки и загрузки справочников. Выгрузка осуществляется только в Excel в одном немодифицируемом системном формате, без возможности настройки атрибутного состава (полей), все ссылочные данные представлены в виде id на вспомогательные справочники и классификаторы, выгрузка ограничена пакетами в 50000 записей, выгрузка с учетом фасетно-иерархической классификации не реализована в принципе.
  Например, для того чтобы выгрузить весь справочник МТРиУ и привести его в понятный для пользователя формат потребуется потратить несколько часов на выгрузку 5 фрагментов основного справочника, всех вспомогательных справочников и классификаторов, потом свести воедино все фрагменты основного справочника, удалить лишние атрибуты, через id подтянуть значения из вспомогательных справочников, в ручных операциях с учетом особенностей Excel весьма вероятно допустить ошибку. В SAP MDM выгрузка из толстого клиента осуществляется в файлы разных форматов, с настройкой полей, в атрибуты вспомогательных справочников указываются истинные значения, а не их id, скорость выгрузки 250 записей в секунду.
  C загрузкой процесс такой же непростой, для загрузки новых записей придется отключить репликацию, остановить правила качества, сначала загрузить часть информации для получения внешнего id, потом выгрузить загруженные данные, подтянуть внешний id в исходный загрузочный файл, потом вторым проходом догрузить классификацию, запустить репликацию, правила качества. На практике на дозагрузку 150 записей уйдет не менее 2 часов времени и операцию можно проводить только в технологическое окно, пользователи параллельно не могут создавать новые записи. В пакете инструментов SAP есть Import Manager и Syndicator позволяющие быстро и эффективно делать пользовательское карты загрузки, в один проход прогружать справочники, выбирая любой ключ для загрузки, и получать всевозможные выгрузки.

  

• Бизнес-процесс (BPM) для заявок - кастомизационная часть кода.

  В платформе не предусмотрена возможность настраивать некоторые или все бизнес-процессы через модуль BPM. По каким-то неизвестным мне причинам не удалось без программирования реализовать достаточно типовой процесс для 4 основных ролей: Инициатор заявки, Эксперт НСИ, Старший эксперт НСИ, Куратор, с шагами: черновик, подан в обработку, в обработке, направлен на уточнение, возвращен с уточнения, направлен куратору, возвращен куратором, завершен, отклонен. Если один из основных блоков MDM реализован таким образом это вызывает вопросы о зрелости решения.

• Нет ограничений на пакетные операции для пользователей.

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

• Нет ограничений на отображение заявок для пользователей.

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

• Права на редактирование атрибутов заявки не задаются на шаг бизнес-процесса или тип операции.

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

• Проблемы с поисковыми возможностями.

  В платформе реализован поиск по справочникам на движке Elasticsearch. В интерфейсе представлена возможность поиска как по всем полям одновременно (атрибут "Ключевое наименование"), так и по отдельным полям.
  Первая проблема заключается в том, что нет возможности настроить поиск по сочетанию только требуемых содержательных полей (а не всех). Для решения такой проблемы можно только отключить поиск по отдельным полям в принципе, а не в совокупности с другими. На практике получается, что поиск по всем полям фактически не применим, так как в справочнике много атрибутов создающих фон. Например, ищем контрагента вводя ИНН, а находим запись, у которой ИНН другой, а ИНН из поискового запроса похож на код записи в локальной системе. Также стоит отметить что этот поиск выводится по умолчанию как основной в самом верху формы, и пользователю надо еще догадаться, что есть поиск по отдельным атрибутам.
  Вторая существенная проблема, что поиск по отдельным полям нельзя сочетать с поиском по всем полям, это хоть как-то могло решить первую обозначенную проблему.
  Третья проблема, выявленная в эксплуатации, поиск из коробочного решения никаким образом не учитывает взаимное расположение терм в поисковом запросе. Это крайне негативно влияет на результаты поиска по отдельным специфическим поискам. Например, поиск по обозначениям ТУ, возьмем для примера распространенные "ТУ 16.К71-310-2001" на кабели, Elasticsearch разбирает этот запрос на выражение типа '%ТУ%' and '%16%' and '%К71%' and '%310%'  and '%2001%', то есть игнорирует символы разделителей (точки, дефисы) и их взаимное расположение, в результате из 200000 записей справочника выводится более 55000 найденных записей, кабелей с запрошенными ТУ на первых страницах нет (в самых релевантных результатах), хотя в справочнике их сотни и поиск по "%ТУ 16.К71-310-2001%" сразу бы их нашел.
  Четвертая проблема в том, что некоторые поисковые запросы не просто не выводятся в топ, а не находятся в принципе. Например, в справочнике есть ряд приборов серии "Метран-300", поиск по данной серии, один в один входящей в наименование выводит почему-то только одну запись, также поиск по разным атрибутам выводит разные результаты. Например, в поле 1 и поле 2 есть точное соответствие поисковому запросу, поиск по полю один выведет одно количество, поиск по полю 2 другое количество.Пятая проблема, просили реализовать поиск с учетом латиницы и кириллицы, одинаковых по написанию. С учетом того, что решение идет в рамках "импортозамещения", была надежда, что отечественная компания уделить внимание проблеме с символами национального алфавита. Можно понять, когда западные компании игнорируют проблемы аборигенных нелатинских языков, но в русскоязычных справочниках это постоянная проблема, отечественный разработчик, который "в материале" мог бы понять важность проблемы и решить ее.
  Также обращались по возможностям настройки поиска в части применения кавычек. В современных поисковых системах давно уже используется полезный механизм точного поиска (содержит), путем заключения поискового запроса в кавычки, снова куча проблем и отказ в реализации.
  В SAP MDM аналогичный поиск настраивается по сочетанию полей и комбинируется с запросами по отдельным полям, реализован проще, но тем не менее дает релевантный результат. В целом этот ключевой модуль вызывает много вопросов, сложилось впечатление, что у разработчика нет компетенций в вопросе поисковых алгоритмов, предметную область справочников они не знают, предлагают нам самостоятельно ознакомиться с алгоритмами Elasticsearch и сказать какой алгоритм задать, проблема не решается уже более 3 месяцев. Очевидно слабое место системы.

  

• Нет возможности добавления атрибутов заявки.

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

  

• Отсутствие возможности настраивать обязательность заполнения по триггерной логике.

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

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

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

  

• В системе не предусмотрена фильтрация заявок по операциям создание/изменение/удаление/восстановление.

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

• Нет возможности настраивать для записей классификаторов и вспомогательных справочников применимость в других справочниках.

  Простыми словами, для записи справочника или узла классификатора невозможно задать признак, отвечающий за его отображение и возможность выбора (ссылки на него) в других справочниках. Например, MDM выступает мастер-системой для справочника единиц измерения, часть единиц измерения используется в сугубо специфических прикладных бизнес-процессах (например, для оценки технического состояния оборудования в системе ТОРО), такие специфические ЕИ хотелось бы заблокировать для применения в справочнике МТРиУ, где используются только учетные и закупочные ЕИ, но настроить такое стандартными средствами возможности нет. Деление на отдельные справочники однотипных сущностей также не целесообразно.

• Проблемы с разделением на понятия запрос на изменение и запрос на добавление записи.

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

• Сырая проработка фасетно-иерархических классификаторов.

  Сложилось впечатление, что фасетно-иерархические (онтологические) классификаторы появились в системе совсем недавно и никто из разработчиков толком не изучал пользовательский опыт и методологию применения таких классификаторов. Есть ряд конкретных замечаний: в системе невозможно привязывать одно свойство (атрибут класса) к нескольким узлам классификации, сортировка свойств только по алфавиту, нет возможности добавления дополнительных параметров атрибута (например, параметр для сортировки, атрибут "Единица измерения" для свойств с числовыми характеристиками, псевдоним и т.д.), значения свойств добавляются только в отдельном интерфейсе администратора (в SAP MDM реализована функция добавления отсутствующих значений на лету, из формы кодирования записи), не оптимизирован интерфейс отображения свойств (ширина отображения названий атрибутов не регулируется, одно название свойства растягивается на несколько строк по одному слову, получается огромная зона, чтобы пролистать ее до основных атрибутов записей приходится много прокручивать).

  

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

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

• Запрос на изменение инициируется путем редактирования карточки записи.

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

• Заявка декомпозирована на задачи.

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

  

Эргономика и интерфейс пользователя

• Основной тип отображения данных «Плитка».

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

• Неудобная фильтрация и поиск заявок и записей, поисковые формы не хранятся в персональных настройках, их нельзя задавать в системных настройках.В системе реализован принцип единого интерфейса для обработки заявок пользователей и поиска по справочникам, то есть заявки на разные справочники и записи попадают в один универсальный интерфейс, без возможности разделить потоки на разные более специализированные интерфейсы. Эта универсальность серьезно ухудшает эргономику отборов и фильтрации заявок и записей. Реализуется принцип раскрытия поисковых атрибутов, когда атрибуты для поиска появляются только после выбора ключевого значения (например, справочника). На практике Эксперт (Data Steward) вынужден при каждом входе персонализировать отображаемые атрибуты для поиска, так как в пользовательских настройках это не сохраняется.Настройка положения поисковых атрибутов в форме поиска не предусмотрена, операторы поиска также не настраиваются (безальтернативно задано "точное соответствие", хотя преимущественно требуется "содержит"). Все это очень напоминает сказку про кощея, "На море на океане есть остров, на том острове дуб стоит, под дубом сундук зарыт, в сундуке — заяц, в зайце — утка, в утке — яйцо, в яйце — игла, — смерть Кощея". Ситуацию не изменяет и права на справочники, даже если у пользователя права на один справочник, каждый раз он должен его выбирать, настраивать нужные ему атрибуты и операторы. На мой взгляд это серьезный просчет, правильнее было бы одновременно поддерживать 2 стратегии - специализированную, выделение заявок по отдельным справочникам в отдельные интерфейсы, где все нужные атрибуты отображены по умолчанию и универсальную, один общий интерфейс, где можно смотреть все заявки, так как зачастую, либо есть специализация у пользователей и экспертов или поток заявок по некоторым справочникам пренебрежимо мал, чтобы жертвовать эргономикой в самой массовой части ради них.Сама поисковая форма имеет вертикальную ориентацию, что на мой взгляд также неудачное решение, если бы она располагалась горизонтально, все атрибуты помещались в один экран не было бы необходимости использовать прокрутку.

  

  Форма поиска по заявкам, выбор справочника (МТРиУ, изображение слева) приводит к появлению в самом низу поисковой формы возможности отбора по атрибутам данного справочника (изображение справа)

• Не настраивается расположение блока атрибутов классификации.

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

  

• При назначении заявок не обновляется их перечень.

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

• В заголовки вкладок браузера не выводятся названия открытых разделов.

  Как правило, сценарий, когда пользователь работает только в одной вкладке системы не самый распространенный. Практика показывает, что для роли Эксперт (Data Steward) нужно около 3-4 вкладок под различные операции. В SAP MDM на вкладках браузера выводился заметный заголовок открытого раздела интерфейса, ориентироваться очень удобно. В решении Юнидата все вкладки неразличимы, а так как интерфейс работы с заявкой во вкладке "Запись" не отличается от карточки записи в справочнике, нередко пользователи начинают редактировать существующую запись справочника, случайно подавая запрос на изменение вместо запроса на добавление.

  

• Нет возможности добавить несколько документов одним действием.

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

• Не проработаны текстовые поля для редактирования.

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

  

• Повышенная трудоемкость ввода данных в атрибуты (поля).

  Согласно проведенным сравнительным испытаниям ввод одних и тех же заготовленных данных в систему UniData MDM занял на 75-100 % больше времени (в зависимости от кейса), чем в SAP MDM. После оптимизации как пользовательского интерфейса (UI), так и производительности системы, удалось снизить значение до 50 %.

• В форме выбора узла классификатора нет кнопки "раскрыть все".

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

  

• В системе не предусмотрено хранение атрибуты "Отчество" для пользователя.

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

  Администрирование и доработки.

• Проблемы с передачей данных в системы-получатели.

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

• Модуль подписки и публикации (PubSub) не позволяет задавать id сообщения на пакет записей.

  Например, в нашем ландшафте есть "тяжелая" система-получатель, настройки которой позволяет принимать 1 пакет раз в 4 минуты. SAP MDM позволяет формировать пакеты по несколько записей, в Юнидата MessageID задается на запись, а не пакет. На практике это выливается в проблему прогрузки достаточно массовых изменений через интеграционную шину, например, чтобы передать в упомянутую систему изменения по 1000 записей понадобится 4000 минут.В самом модуле PubSub нет возможности важных для работы атрибутов (например, основного идентификатора, применяемого в системе, так как с GUID мы не работаем, исполнителя для понимания в чьей сфере ответственности задача по исправлению ошибки, нет расшифровок ошибок от систем-получателей, они только в почтовых сообщениях и еще ряд неудобств).

  

• Качество программного кода.

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

• Трудоемкость доработок на 30-50 % выше аналогичных в SAP MDM.

  В данном пункте стоит упомянуть, что поддержка SAP MDM осуществлялась своими силами, а поддержка платформы Юнидата осуществляется через подрядчика, возможно это накладные расходы, формируемые подрядчиком, тем не менее факт таков, трудоемкость в человеко-часах как правило выше на 30-50 % чем в SAP MDM.

Выводы*

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

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

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

Сказывается и малая практика внедрения данной платформы под задачи ведения промышленных справочников МТР. Насколько я понял, помимо нашей Группы компаний, чуть раньше, подобный проект стартовал в ОАО "РЖД", других аналогичных внедрений не было. Предстоит еще много внедрений и доработок, чтобы по функциональности и удобству приблизиться к SAP MDM или иной зрелой системе.

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

Александр Черевичин, специалист НСИ.

*Мнение автора может не совпадать с мнением Заказчика (работодателя).