Как автор цитируемой статьи хотел бы дать несколько комментариев.
1) Горячо приветствую выход Юнидаты в публичную плоскость;
2) Не скрываю свое имя, представился под своим постом, все остальные данные несложно найти, например, в linkedIn;
3) В контексте множественной классификации речь шла о ее безальтернативности, а не о том, что она не применима в принципе. Чтобы все все правильно понимали, прошу честно сообщить, когда эта функциональность появилась в платформе, в этом году? В нашей действующей системе данная настройка появилась на этой неделе, при этом понятие переклассификация по-прежнему не работает (то есть пакетно заменить указанный класс у группы записей на другой возможности нет). Процитирую свою статью:
«Будет уместным добавить, что часть описанных замечаний будет устранена в относительно ближайшей перспективе. Также вероятно, что часть проблем возникла из-за наличия промежуточного звена между заказчиком и разработчиком, в связи с этим приношу свои извинения за возможные неточности, которые могут быть вызваны „испорченным телефоном“ или малым опытом работы с платформой со стороны специалистов подрядчика.»
Резюмируя, приветствую, что вы нас слышите и дорабатываете свою платформу, но кичиться конкретно этим не совсем корректно, проблема была обозначена еще в апреле 2020 года, а реализована только сейчас.
4) С интересом ознакомлюсь со статьей, посвященной механизмам поиска дубликатов, но добавлю, что с текущей функциональностью ознакомился, по составу механизмов сравнения претензий нет, однако в настройках, насколько я успел заметить по-прежнему нет возможности задать границы коэффициента релевантности при нестрогом сравнении (поправьте меня, если не прав).
Также добавлю, что вы рассматриваете задачу поиска дублей как и любой разработчик как поисковый алгоритм, ряд компаний, более продвинувшихся в понимании, что такое поиск дубликатов в справочниках МТР, реализует комбинации алгоритмов поиска и баз знаний (например, «Сервер Онтологии» компании Акселот, «Брэдфорд» ныне канувшей в лету компании Компьютел и др.).
5) В продолжение поисковых возможностей, в своем посте упомянул о задаче поиска с эквивалентным восприятием одинаковых по написанию букв кириллицы и латиницы, правильно я понимаю, что такой кейс не решен в платформе и не решается?
6) Прошу обратить внимание на то, что это только второе внедрение решения в части промышленных справочников МТР (возможно их незначительно больше). Хорошую информационную систему не построить без достаточного референса. На мой взгляд, когда компания пытается зайти на новую для себя поляну отношение «заказчик платит за все» неуместно, платформа должна сама инвестировать в свое развитие и внимательно относиться к стартовым заказчикам, изучать, как данные процессы реализованы на других платформах, а не навязывать мало применимые модели.
В заключение, искренне хочу пожелать успеха в развитии вашего продукта и конструктивного восприятия критики.
Попробую донести свою позицию.
1) Данный пост написан по завершении ОПЭ, проблематика и альтернативные пути ее решения в рамках существующей парадигмы системы проговаривались не раз, исчерпывающее впечатление о платформе и стиле работы команды сложилось полностью. Вся компромиссность разбивается о постоянно звучащую фразу «ограничение платформы».
2) Содержание субъективных оценочных суждений в посте не превышает 20%, акцент сделан на фактических трудностях при переходе с работоспособного решения, где все описанное работало, на новое решение, где заметная часть не реализуема стандартными средствами или альтернатива заметно ухудшает качество, трудоемкость и эргономику операций. Напомню ключевой тезис из ТЗ «с полным сохранением функциональности». Каждый сам для себя сделает вывод.
3) Прошу обратить внимание на то, что это только второе внедрение решения в части промышленных справочников МТР (возможно незначительно больше). Хорошую информационную систему не построить без достаточного референса, на мой взгляд, когда компания пытается зайти на новую для себя поляну отношение «заказчик платит за все» неуместно, платформа должна сама инвестировать в свое развитие и внимательно относиться к стартовым заказчикам, изучать как данные процессы реализованы на других платформах, а не навязывать мало применимые модели.
Правильно я понимаю, что под прямыми аналогами подразумеваются только оригинальные кросс-номера запасных частей? Сложно поверить, что такой эффект достигается только за счет связи «оригинальная з/ч — оригинальная з/ч-заменитель».
С некоторыми крупнейшими поставщиками в принципе крайне сложно выстроить процесс получения информации по номерам-заменителям. Более того, отдельные поставщики преднамерено в документации приводят номера транзакционного характера (например, состоящего из id покупателя, id заказа и номера позиции в заказе).
Анастасия, можно еще добавить четвертый подход к подбору аналогов — аналоги выбранные на торгах по решению закупочной комиссии (когда в процессе торгов поставщик предложил другой вариант, одобренный ЗК). Данный сценарий хоть и более субъективный, тем не менее его проще всего реализовать. Правда сработает он только в случае, если в информационных системах компании можно проследить сквозняком процесс от формирования потребности до фактической поставки конкретного МТР.
На момент первого знакомства с платформой не удалось найти каких-либо отзывов и описаний практик внедрения, пришлось на свои грабли наступать, основная цель поделиться опытом, без какого-либо иного подтекста.
К сожалению, из соображений корпоративной этики я не могу комментировать данную сторону вопроса. Тем не менее, если рассуждать объективно, факт внедрения данного решения отбросил функциональность системы по управлению НСИ на несколько лет назад, наверстывание происходит уже на стадии эксплуатации, а не проектирования и разработки системы. И важно отметить, что большая часть того, что было реализовано в SAP MDM стандартными средствами, в Юнидата реализуется как кастомизация (это головная боль при сопровождении любой информационной системы).
1) Горячо приветствую выход Юнидаты в публичную плоскость;
2) Не скрываю свое имя, представился под своим постом, все остальные данные несложно найти, например, в linkedIn;
3) В контексте множественной классификации речь шла о ее безальтернативности, а не о том, что она не применима в принципе. Чтобы все все правильно понимали, прошу честно сообщить, когда эта функциональность появилась в платформе, в этом году? В нашей действующей системе данная настройка появилась на этой неделе, при этом понятие переклассификация по-прежнему не работает (то есть пакетно заменить указанный класс у группы записей на другой возможности нет). Процитирую свою статью:
«Будет уместным добавить, что часть описанных замечаний будет устранена в относительно ближайшей перспективе. Также вероятно, что часть проблем возникла из-за наличия промежуточного звена между заказчиком и разработчиком, в связи с этим приношу свои извинения за возможные неточности, которые могут быть вызваны „испорченным телефоном“ или малым опытом работы с платформой со стороны специалистов подрядчика.»
Резюмируя, приветствую, что вы нас слышите и дорабатываете свою платформу, но кичиться конкретно этим не совсем корректно, проблема была обозначена еще в апреле 2020 года, а реализована только сейчас.
4) С интересом ознакомлюсь со статьей, посвященной механизмам поиска дубликатов, но добавлю, что с текущей функциональностью ознакомился, по составу механизмов сравнения претензий нет, однако в настройках, насколько я успел заметить по-прежнему нет возможности задать границы коэффициента релевантности при нестрогом сравнении (поправьте меня, если не прав).
Также добавлю, что вы рассматриваете задачу поиска дублей как и любой разработчик как поисковый алгоритм, ряд компаний, более продвинувшихся в понимании, что такое поиск дубликатов в справочниках МТР, реализует комбинации алгоритмов поиска и баз знаний (например, «Сервер Онтологии» компании Акселот, «Брэдфорд» ныне канувшей в лету компании Компьютел и др.).
5) В продолжение поисковых возможностей, в своем посте упомянул о задаче поиска с эквивалентным восприятием одинаковых по написанию букв кириллицы и латиницы, правильно я понимаю, что такой кейс не решен в платформе и не решается?
6) Прошу обратить внимание на то, что это только второе внедрение решения в части промышленных справочников МТР (возможно их незначительно больше). Хорошую информационную систему не построить без достаточного референса. На мой взгляд, когда компания пытается зайти на новую для себя поляну отношение «заказчик платит за все» неуместно, платформа должна сама инвестировать в свое развитие и внимательно относиться к стартовым заказчикам, изучать, как данные процессы реализованы на других платформах, а не навязывать мало применимые модели.
В заключение, искренне хочу пожелать успеха в развитии вашего продукта и конструктивного восприятия критики.
1) Данный пост написан по завершении ОПЭ, проблематика и альтернативные пути ее решения в рамках существующей парадигмы системы проговаривались не раз, исчерпывающее впечатление о платформе и стиле работы команды сложилось полностью. Вся компромиссность разбивается о постоянно звучащую фразу «ограничение платформы».
2) Содержание субъективных оценочных суждений в посте не превышает 20%, акцент сделан на фактических трудностях при переходе с работоспособного решения, где все описанное работало, на новое решение, где заметная часть не реализуема стандартными средствами или альтернатива заметно ухудшает качество, трудоемкость и эргономику операций. Напомню ключевой тезис из ТЗ «с полным сохранением функциональности». Каждый сам для себя сделает вывод.
3) Прошу обратить внимание на то, что это только второе внедрение решения в части промышленных справочников МТР (возможно незначительно больше). Хорошую информационную систему не построить без достаточного референса, на мой взгляд, когда компания пытается зайти на новую для себя поляну отношение «заказчик платит за все» неуместно, платформа должна сама инвестировать в свое развитие и внимательно относиться к стартовым заказчикам, изучать как данные процессы реализованы на других платформах, а не навязывать мало применимые модели.
С некоторыми крупнейшими поставщиками в принципе крайне сложно выстроить процесс получения информации по номерам-заменителям. Более того, отдельные поставщики преднамерено в документации приводят номера транзакционного характера (например, состоящего из id покупателя, id заказа и номера позиции в заказе).