Рады приветствовать Вас на корпоративной странице компании «Юнидата». В последнее время имя нашей компании все чаще стало звучать на «Хабре», что сподвигло нас создать свой корпоративный блог, в котором мы будем писать об управлении данными, руководстве данными, анализировать основные тренды в области Data Management. Словом, делиться на просторах «Хабра» разными интересными материалами в области данных, что обычно мы делали в рамках нашего Сообщества экспертов по управлению данными.
Среди тем, которые мы будем регулярно затрагивать в своем блоге – управление данными, руководство данными (Data Governance), качество данных (Data Quality), основные тренды в области данных, методология внедрения в области управления данными, DAMA-DMBOK и многое другое.
Тема первой публикации лежит на поверхности. Несколько дней назад в «Песочнице» вышла объемная статья под названием «Опыт знакомства с MDM решением компании Юнидата (UniData)», в которой автор из неназванной компании рассказывает об опыте замещения иностранного решения нашей платформой.
Статья получилось объемная, с множеством иллюстраций и примеров, однако она грешит известным схематизмом и, увы, негативом. Рассматриваются многие минусы, но не говорится о плюсах, что заставляет задуматься об объективности автора. Возможно, это связано со следующим наблюдением, которое мы сделали за годы внедрения платформы: при переходе на новый технологический уровень некоторые коллеги, держась за свой старый опыт и приверженность любимым решениям, пусть даже и очень старым, зачастую не готовы меняться и развиваться вслед за новыми технологиями в области управления данными.
Анализировать подробно все не будем, публикация, в целом, довольно странная, но на некоторых моментах любопытно остановиться подробнее.
Цитата первая. Отсутствие понятия «легитимное состояние записи».
После создания черновика заявки на добавление или изменение записи, изменения сразу же отображаются в справочнике. Например, пользователь добавил запись или внес в нее изменения (мог даже не подать заявку, а просто сохранить как черновик), изменения сразу же отображаются в справочнике и видны всем пользователям. Как следствие данные искажаются и рассинхронизируются с версиями в локальных системах-получателях, что путает пользователей, появляется вероятность внесения дублей, некорректно работают проверки, отборы и возникает ряд других трудностей и неудобств.
Реальность. Основная драма в том, что речь просто идет о новом и от того не привычном пользовательском интерфейсе, с которым автор статьи в силу естественных причин не успел познакомиться. А также в том, что в компаниях зачастую создаются собственные понятия о «легитимном состоянии записей», основанные на предыдущем опыте. Нам бы хотелось на данном примере отделить концепцию «единой версии правды» в работе с основными данными и тонкости работы с записями в пользовательском интерфейсе.
С точки зрения платформы мы отображаем состояние черновика записи с той целью, чтобы пользователи системы могли увидеть планируемые изменения в карточке записи. При этом записи в статусе «На согласовании» не публикуются в системы-получатели, до тех пор, пока внесенные в черновик изменения не будут успешно согласованы в бизнес-процессе. Так же хотелось бы упомянуть, что интерфейс платформы поддерживает возможность фильтрации записей, находящихся в статусе «На согласовании», благодаря которой можно как скрывать от пользователя такие записи, так и отображать в общей поисковой выдаче опубликованных записей.
Про собственный механизм автоматического поиска дубликатов в нашей платформе мы напишем отдельный материал. Есть основания полагать, что до внедрения нашей платформы с такими инструментами автор попросту не работал, от этого делается такой негативный акцент, именно на риске получения дубликатов, с которыми, как нам видится, боролись вручную.
Цитата вторая. Множественная классификация.
В системе безальтернативно реализована модель данных, предусматривающая множественную классификацию, при которой одной записи можно присвоить несколько классов одного классификатора. Как правило, для большинства справочников МТР множественная классификация не допускается на уровне методологии. Следствием такой реализации является отсутствие понятия «переклассификация» при использовании стандартной пакетной операции загрузки или пакетной модификации в интерфейсе (update) существующих записей справочника. Если вместо указанного класса привести ссылку на другой класс, то существующий класс при загрузке и модификации в интерфейсе не заменяется, а добавляется как второй.
Реальность. Платформа является универсальной и работает в большом количестве отраслей, в которых зачастую не обойтись без множественной классификации, даже с учетом всех апелляций к ГОСТам, методологиям и вообще справедливости. Однако в реальности, например, контрагенты могут иметь несколько классов по ОКВЭД и т.д. При этом данный пункт отчетливо показывает невысокий уровень владения платформой, т.к. множественную классификацию можно сразу же отключить прямо в интерфейсе.
Цитата третья. В платформе реализован поиск по справочникам на движке Elasticsearch.
В интерфейсе представлена возможность поиска как по всем полям одновременно (атрибут «Ключевое наименование»), так и по отдельным полям. Первая проблема заключается в том, что нет возможности настроить поиск по сочетанию только требуемых содержательных полей (а не всех) etc.
Реальность. Отметим, что абсолютно все поисковые технологии имеют ограничения, но это заслуживает отдельного материала, связанного с управлением данными и мы обязательно это осветим в ближайших публикациях. Однако опять же основной акцент – в старом интерфейсе было удобно и привычно. Для пользователей, незнакомых с MDM платформой, нужно сделать важный дисклеймер: вы ищите данные в реестрах и справочниках, которые вы смоделировали сами, соответственно от это зависит и возможность создания поисковых запросов. Обозначенная в статье поисковая форма работает по принципу «найти хоть что-нибудь похожее» и имеет довольно широкие настройки анализаторов, вследствие чего в поисковую выдачу попадает много шумовых данных. Для более четкого поиска необходимо указывать конкретные поисковые атрибуты, и тогда результат будет соответствовать ожиданиям пользователя.
Цитата четвертая. В системе не предусмотрено хранение атрибуты «Отчество» для пользователя.
Причины понятны, продукт начинал свое движение на западе, тем не менее в России все-таки обращение просто по имени не принято, вызывает определенный дискомфорт при попытке связаться с пользователем. Напомню, решение продвигается как импортозамещающее.
Реальность. Автор решил не представляться и не говорить, о том, в рамках каких проектов, целей и условий проводится внедрение. И даже не обозначил из какой он компании (хотя, конечно же, это и так понятно по скриншотам). Однако аппелирует к тому, что вежливость платформы не соответствует его организации. При этом постоянно приводятся сравнения с продуктом, который уж точно не начинал свое движение в России, в то время как наша платформа уж точна написана в России с первого дня. В то же время, считаем данное замечание дельным. Добавим в роадмап продукта.
Хотелось бы отметить, что процесс разработки и интеграции новых инструментов — это не только техника, но и новый пользовательский опыт, который мы стараемся использовать для улучшения качества и дальнейшего развития платформы. Исходя из этого, будет регулярно постить на «Хабре» новые статьи об управлении данными.
До встречи!
