Comments 5
Управление данными это всегда интересно. Буду ждать новых статей.
Большинство тезисов исходной статьи представляют собой обычные заявки на доработку. Видно, что автор той статьи словил негатив из-за разрыва ожиданий и фактического результата, и даже не упомянул (умышленно?), что большинство проблем, которые он испытывал, связаны с аналитикой перед внедрением. То есть, ему бы с этими бедами идти к аналитикам своей компании, и спрашивать, почему так всё плохо вышло
Могу только согласиться со следующими пунктами:
Правда, я ещё не встречал ни одной крупной системы (управления данными и не только), в которой было бы всё идеально и удобно. Например, гляньте на скриншоты SAP MDM, там-то классификаторы удобные)
p.s. вообще, у меня мысль уплыла. Хотел сказать, что эта статья выглядит как статья-разоблачение, что, наверное, нужно, но я бы хотел почитать и другой контент по mdm
Могу только согласиться со следующими пунктами:
- действительно, было бы неплохо иметь возможность добавить отчество. Однако, напомню, что, в РФ, например, отчество является необязательным атрибутом, и любой гражданин в праве его не указывать.
- выводить динамический заголовок во вкладке браузер
- ввод данных в поля записей выглядит действительно неудобным, но тут надо смотреть контекст: набивают ли данные от руки или загружают огромную пачку и лишь редактируют
- классификаторы выглядят не самоочевидными
Правда, я ещё не встречал ни одной крупной системы (управления данными и не только), в которой было бы всё идеально и удобно. Например, гляньте на скриншоты SAP MDM, там-то классификаторы удобные)
p.s. вообще, у меня мысль уплыла. Хотел сказать, что эта статья выглядит как статья-разоблачение, что, наверное, нужно, но я бы хотел почитать и другой контент по mdm
Как автор цитируемой статьи хотел бы дать несколько комментариев.
1) Горячо приветствую выход Юнидаты в публичную плоскость;
2) Не скрываю свое имя, представился под своим постом, все остальные данные несложно найти, например, в linkedIn;
3) В контексте множественной классификации речь шла о ее безальтернативности, а не о том, что она не применима в принципе. Чтобы все все правильно понимали, прошу честно сообщить, когда эта функциональность появилась в платформе, в этом году? В нашей действующей системе данная настройка появилась на этой неделе, при этом понятие переклассификация по-прежнему не работает (то есть пакетно заменить указанный класс у группы записей на другой возможности нет). Процитирую свою статью:
«Будет уместным добавить, что часть описанных замечаний будет устранена в относительно ближайшей перспективе. Также вероятно, что часть проблем возникла из-за наличия промежуточного звена между заказчиком и разработчиком, в связи с этим приношу свои извинения за возможные неточности, которые могут быть вызваны „испорченным телефоном“ или малым опытом работы с платформой со стороны специалистов подрядчика.»
Резюмируя, приветствую, что вы нас слышите и дорабатываете свою платформу, но кичиться конкретно этим не совсем корректно, проблема была обозначена еще в апреле 2020 года, а реализована только сейчас.
4) С интересом ознакомлюсь со статьей, посвященной механизмам поиска дубликатов, но добавлю, что с текущей функциональностью ознакомился, по составу механизмов сравнения претензий нет, однако в настройках, насколько я успел заметить по-прежнему нет возможности задать границы коэффициента релевантности при нестрогом сравнении (поправьте меня, если не прав).
Также добавлю, что вы рассматриваете задачу поиска дублей как и любой разработчик как поисковый алгоритм, ряд компаний, более продвинувшихся в понимании, что такое поиск дубликатов в справочниках МТР, реализует комбинации алгоритмов поиска и баз знаний (например, «Сервер Онтологии» компании Акселот, «Брэдфорд» ныне канувшей в лету компании Компьютел и др.).
5) В продолжение поисковых возможностей, в своем посте упомянул о задаче поиска с эквивалентным восприятием одинаковых по написанию букв кириллицы и латиницы, правильно я понимаю, что такой кейс не решен в платформе и не решается?
6) Прошу обратить внимание на то, что это только второе внедрение решения в части промышленных справочников МТР (возможно их незначительно больше). Хорошую информационную систему не построить без достаточного референса. На мой взгляд, когда компания пытается зайти на новую для себя поляну отношение «заказчик платит за все» неуместно, платформа должна сама инвестировать в свое развитие и внимательно относиться к стартовым заказчикам, изучать, как данные процессы реализованы на других платформах, а не навязывать мало применимые модели.
В заключение, искренне хочу пожелать успеха в развитии вашего продукта и конструктивного восприятия критики.
1) Горячо приветствую выход Юнидаты в публичную плоскость;
2) Не скрываю свое имя, представился под своим постом, все остальные данные несложно найти, например, в linkedIn;
3) В контексте множественной классификации речь шла о ее безальтернативности, а не о том, что она не применима в принципе. Чтобы все все правильно понимали, прошу честно сообщить, когда эта функциональность появилась в платформе, в этом году? В нашей действующей системе данная настройка появилась на этой неделе, при этом понятие переклассификация по-прежнему не работает (то есть пакетно заменить указанный класс у группы записей на другой возможности нет). Процитирую свою статью:
«Будет уместным добавить, что часть описанных замечаний будет устранена в относительно ближайшей перспективе. Также вероятно, что часть проблем возникла из-за наличия промежуточного звена между заказчиком и разработчиком, в связи с этим приношу свои извинения за возможные неточности, которые могут быть вызваны „испорченным телефоном“ или малым опытом работы с платформой со стороны специалистов подрядчика.»
Резюмируя, приветствую, что вы нас слышите и дорабатываете свою платформу, но кичиться конкретно этим не совсем корректно, проблема была обозначена еще в апреле 2020 года, а реализована только сейчас.
4) С интересом ознакомлюсь со статьей, посвященной механизмам поиска дубликатов, но добавлю, что с текущей функциональностью ознакомился, по составу механизмов сравнения претензий нет, однако в настройках, насколько я успел заметить по-прежнему нет возможности задать границы коэффициента релевантности при нестрогом сравнении (поправьте меня, если не прав).
Также добавлю, что вы рассматриваете задачу поиска дублей как и любой разработчик как поисковый алгоритм, ряд компаний, более продвинувшихся в понимании, что такое поиск дубликатов в справочниках МТР, реализует комбинации алгоритмов поиска и баз знаний (например, «Сервер Онтологии» компании Акселот, «Брэдфорд» ныне канувшей в лету компании Компьютел и др.).
5) В продолжение поисковых возможностей, в своем посте упомянул о задаче поиска с эквивалентным восприятием одинаковых по написанию букв кириллицы и латиницы, правильно я понимаю, что такой кейс не решен в платформе и не решается?
6) Прошу обратить внимание на то, что это только второе внедрение решения в части промышленных справочников МТР (возможно их незначительно больше). Хорошую информационную систему не построить без достаточного референса. На мой взгляд, когда компания пытается зайти на новую для себя поляну отношение «заказчик платит за все» неуместно, платформа должна сама инвестировать в свое развитие и внимательно относиться к стартовым заказчикам, изучать, как данные процессы реализованы на других платформах, а не навязывать мало применимые модели.
В заключение, искренне хочу пожелать успеха в развитии вашего продукта и конструктивного восприятия критики.
Sign up to leave a comment.
Время поговорить об MDM