Что такое MDM?

1.

Об опасности заимствования западной методологии нормализации и ведения Справочника МТР по шаблонам свойств-значений

Досадную, непростительную ошибку мы совершили в далеком 2007 году: ФГУ «Федеральный центр каталогизации» Росстандарта (а мне довелось в те годы работать в этой организации) пригласил в Россию Южно-африканскую компанию “RAMIS”. Сначала – на Международную конференцию по каталогизации с целью информировать техсообщество о новом стандарте параметрического описания продукции ISO 22745, а затем – мы свели их с руководством одной из крупнейших отечественных металлургических компаний с целью «реализовать идеи на практике».

К тому времени на отечественном ИТ-рынке не только SAP/IBM/Oracle, но и ряд отечественных компаний стали активно продвигать практику нормализации и автосборки наименований закупаемой продукции по примитивным, односложным шаблонам свойств-значений. То, что с внедрением этой практики резко «просело» качество нормативно-справочной информации (НСИ) – это считалось временным явлением и объяснялось новизной методологии.

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

Основная техническая часть этой статьи была написана еще весной 2022 года и имела целью исключительно узкопрофессиональную критику одной из привнесенных с Запада ИТ-методологий. Сегодня же есть смысл взглянуть на проблему и с точки зрения «конспирологии»: а не случайны ли эти «закладки»? Не повторение ли это аферы с СОИ 80-х годов, приведшей к перегрузке нашей экономики непроизводительными затратами?

https://habr.com/ru/post/703970/?utm_source=habrahabr&utm_medium=rss&utm_campaign=703970

Невозможно представить современную информационную систему (далее – ИС), которая бы стояла особняком, и не была бы интегрирована с другими. Особенно, если мы говорим о корпоративных или государственных данных. Вопросу интеграций посвящены целые книги, такие как «Шаблоны интеграции корпоративных приложений» Грегора Хопа. Некоторые издания пытаются рассматривать не только технические, но и организационные вопросы интеграции (например, «Предметно-ориентированное проектирование (DDD)» Эрика Эванса). Между тем, современный уровень технологий и высокий уровень компетентности разработчиков очень сильно снижает технические риски, выставляя на первый план организационные. В этой статье мы рассмотрим интеграции информационных систем именно с точки зрения организационных рисков.

https://habr.com/ru/post/696102/?utm_source=habrahabr&utm_medium=rss&utm_campaign=696102

Один из мифов по поводу MDM-систем — «ну что там делать-то, данные взяли, записи объединили, вот тебе и готово. А вы, мол, за работу миллионы хотите. Мы сами всё за полгода сделаем».

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

https://habr.com/ru/post/690460/?utm_source=habrahabr&utm_medium=rss&utm_campaign=690460

В предыдущей нашей публикации, «Как мы писали книгу по управлению данными» мы подробно рассказали о всех нюансах создания книги «Ценность Ваших Данных» [2] – от замысла до работы с издательством. В этой статье мы расскажем о создании труда с точки зрения научной составляющей – от нашего перевода и научной редактуры DAMA-DMBOK2 до создания собственной работы в области управления данными. В данной публикации хотелось бы еще раз проследить историю создания книги, более подробно рассмотрев основные вехи в формировании ее концепции. Во-первых, чтобы дополнительно прояснить замысел авторов. А во-вторых, чтобы поделиться полученным опытом трансформации изначального замысла в процессе написания и подготовки окончательного варианта текста. Возможно, изложенные нами сведения окажутся интересными как для читателей книги, так и для тех коллег, которые планируют издание собственного труда подобного рода.

Отправная точка

Началось все с того, что в течение 2018-2019 годов мы приняли участие в работе над переводом и научной редактурой второго издания руководства Международной ассоциации управления данными (DAMA) к своду знаний по управлению данными - DAMA-DMBOK2 [7]. Наша компания включилась в эту деятельность совершенно осознанно, поскольку мы хорошо понимали важность и полезность переводимого документа, уже давно ориентировались в своей проектной работе на его основные положения и англоязычный текст был нам хорошо знаком. Работа, с учетом необходимых организационных и подготовительных мероприятий, длилась почти полтора года. Особенно напряженными были последние шесть месяцев, когда первоначальный вариант перевода был подвергнут кардинальной переделке, связанной с преодолением целого ряда препятствий [4]. Тем приятнее осознавать, что результат нашего труда оказался востребованным. Мы получили много положительных отзывов о русском издании DMBOK2, его тираж уже несколько раз допечатывался, а варианты перевода отдельных терминов и ключевые текстовые фрагменты все чаще используются в различных отечественных публикациях.

https://habr.com/ru/post/678316/?utm_source=habrahabr&utm_medium=rss&utm_campaign=678316

В прошлый раз я подробно рассказывал об особенностях компании-вендора. Теперь настало время поговорить о мифах и правде в работе компании-вендора. Если тема вам интересна, то давайте начнём.

Миф 1. Особые продуктовые специалисты

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

Попробуем разобраться с качествами технического специалиста, которыми мы чаще всего оперируем для оценки в жизни:

Хороший vs Плохой

Соблазн применить эту категорию очень велик. «Хорошесть» или «плохость» не зависит от места работы, опыта работы, роста или цвета глаз. Это интегральная экспертная оценка ;-). Хорошего программиста видно по его коду, который компактен, понятен, легко поддерживается. Хорошего QA видно по въедливости, упорядоченности и понятности его кейсов. Видно его по вопросам, которые он задет до/при реализации/тестировании.

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

https://habr.com/ru/post/663096/?utm_source=habrahabr&utm_medium=rss&utm_campaign=663096