Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / OLAP и DWH Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3]      все
 Re: Опрос МастерДата  [new]
Roman Kolchin
Member

Откуда:
Сообщений: 188
Alex_496
Вам, как владельцу ERP / АБС / CRM - нужны все эти доп. напруги помимо своего функционала?

Ну я же не про технику писал!! Все ваши аргументы про равноудаленность MDM от прочих систем я понимаю я поддерживаю.

Я задавал вопрос про организацию выделенного управления НСИ, которая будет принимать заявки и своими руками что-то в системе управления НСИ/MDM править.

Зачем это подразделение?

В чем красота получившегося бизнес-процесса: инициатор изменения -> заявка (ручная по почте? в 3-й системе?) -> супермены из управление НСИ -> система MDM?

Разве не лучше: инициатор изменения -> заявка на изменение внутри MDM (по сути драфт новой записи или иерархии) -> автоматические проверки в MDM -> владелец справочника (из соответствующего бизнеса, или аналитик из основной системы-потребителя типа ERP/CRM). Меньше участников, участники лучше понимают задачи учета, в которых используются справочники.

Я на самом деле видел службы НСИ в различных конторах и именно поэтому не считаю их единственно правильным способом организации во всех ситуациях. Там где я видел они по сути были отдельной группой аналитиков в рамках поддержки какой-то основной системы типа SAP, Oracle EBS или Siebel. Под громким названием "централизованное НСИ" подразумевалась всего лишь поддержка модуля большой системы, в целях функционирования этой системы с минимальным учетом интересов остальных потребителей.
16 фев 17, 22:26    [20219598]     Ответить | Цитировать Сообщить модератору
 Re: Опрос МастерДата  [new]
Alex_496
Member

Откуда: Moscow https://www.dvbi.ru
Сообщений: 3491
Roman Kolchin,

ааа......понял, о чем вопрос.

я за вариант 2, точнее даже так:
инициатор изменения = он же владелец экспертизы --> вносит изменения в справочник MDS (в системе комплекс бизнес проверок)--> [если есть другие владельцы экспертизы уведомляются по email -- > вносят изменения в этот же справочник MDS данные по другим полям] -- > остальные отв. лица уведомляются по email

но по некоторым справочникам не удается привлечь/ заставить своевременно вносить данные, т.к. текучка / ленивые пользователи

вопрос переходит в качество менеджмента, поощрения

еще на фазе MDS --> DWH контрольные проверки
автоматические рассылки custom-сообщений (настраиваемые, thnx to Voyager_lan) заинтересованным лицам, в т.ч. и руководству ...и подобное воздействие, "мягкая сила" через email имеет положительный результат
16 фев 17, 23:39    [20219707]     Ответить | Цитировать Сообщить модератору
 Re: Опрос МастерДата  [new]
Roman Kolchin
Member

Откуда:
Сообщений: 188
javajdbc
...у меня попроще системы...никаких реал-тайм проверок Екселей нет.
Никаких конкурируюших апдейтов...
Никаких переводов бизнес атрибутов на технические атрибуты тоже нет.
Как договорились по формату, удобного для бизнеса,
так и грузим в stage. А потом уже и
валидируем в ETL-е и переводим в технические атрибуты...

Т.е. у меня в основном MDS как контроль над справочниками и
интеграционными линками для нужд DWH.

У вас MDS -- насколько я понял -- почти трансакционная фронт-енд аппликация,
с реал-тайм конкурентными апдейтами...

...достаточно разные задачи...

Интересно было бы сравнить сценарии использования.

Опишу мой кейс. Моя основная сфера деятельности -- аналитические приложения типа бюджетного планирования и консолидации на продуктах Oracle Hyperion. Архитектура приложений -- кубы. Измерения кубов часто берутся "из головы" и не содержатся ни в одной другой системе-источнике. Кубов с течением времени становится много.

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

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

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

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

Вендор не предоставляет в составе данных продуктов действительного удобного инструмента для управления всеми этими вещами в масштабах нескольких кубов. Остается только Excel. Или за хорошие деньги Oracle Data Relationship Management.

Какой кейс у вас? На сколько стабильны и неизменны процедуры ETL, которые импортируют справочники в хранилище или аналитические приложения?
17 фев 17, 00:39    [20219771]     Ответить | Цитировать Сообщить модератору
 Re: Опрос МастерДата  [new]
Roman Kolchin
Member

Откуда:
Сообщений: 188
Криво сформулировал:
Roman Kolchin
- измерения частые, не реже одного раза в месяц;

В том то и дело, что изменения НЕ частые, но периодические и с очень жесткими требованиями по срокам.

Кто-нибудь решает подобные задачи?

Пока самое лучшее, что я использовал для этих целей -- Oracle Data Relationship Management.
Основной конкурент, не привяазанный к тому же ни к какому вендору аналитических и ERP-шных приложений -- это Orchestra Networks.

Есть еще удобные инструменты и красивые подходы к решению этих задач?
17 фев 17, 00:49    [20219780]     Ответить | Цитировать Сообщить модератору
 Re: Опрос МастерДата  [new]
javajdbc
Member

Откуда: Montreal
Сообщений: 17545
Roman Kolchin,

как уже говорил, мои кейсы поплоще...ну раз в год меняется
(пополняется) GL, добавляют новые Functional Areas, но это все не критично...
большинство сорсев до ммилиона записей -- когда проходит новый
GL, то просто перегружаю сорсе чтобы зацепить новые Аккаунты и КостЦентры...
есть пара источников трансакций на 30М и 110М записей, но новые ГЛ Аккаунты актуальны
только для ттрансакций последнего года, так что решается частичный апдейтом
(вариант late arrival).

И вообше GL Account мастер лист приходит из SAP отдела,
т.е. даже и проверять неособо надо...

Вообще, DWH предпологает некую стабильность.
Если надо что-то постоянно подкручивать клиентам -- это скорее
"клиентская аппликация" для которой нужно "програмировать"
специализированый интерфейс.
У нас есть такая апликация (не для DWH) -- частично на ИнфоПас-ШереПоинт, частично
на C#, можно было MDS присобачить, но мне было лень
это советовать...
18 фев 17, 05:09    [20223638]     Ответить | Цитировать Сообщить модератору
 Re: Опрос МастерДата  [new]
Roman Kolchin
Member

Откуда:
Сообщений: 188
javajdbc
Если надо что-то постоянно подкручивать клиентам -- это скорее
"клиентская аппликация" для которой нужно "програмировать"
специализированый интерфейс.

Вот-вот, мне и нужна такая аппликация :)
MDS, похоже, для этого не подходят, даже с учетом их бесплатности в составе базы.
18 фев 17, 13:09    [20223961]     Ответить | Цитировать Сообщить модератору
 Re: Опрос МастерДата  [new]
javajdbc
Member

Откуда: Montreal
Сообщений: 17545
Roman Kolchin
javajdbc
Если надо что-то постоянно подкручивать клиентам -- это скорее
"клиентская аппликация" для которой нужно "програмировать"
специализированый интерфейс.

Вот-вот, мне и нужна такая аппликация :)
MDS, похоже, для этого не подходят, даже с учетом их бесплатности в составе базы.


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

Мне просто лень было раскручивать на текущем месте а так вообщето подходит.

Вот еще есть:

www.talend.com/products/mdm/
(free, Apache license)
youtube: S2QJv48tkiQ
19 фев 17, 23:44    [20227052]     Ответить | Цитировать Сообщить модератору
 Re: Опрос МастерДата  [new]
Юрий Кудрявцев
Member

Откуда: Сидней, Австралия
Сообщений: 755
С большим интересом читаю этот топик, у меня очень схожие задачи с вами, Роман, только на месте Hyperion Planning -- IBM TM1 :)

Мы в проектах где есть ETL часть используем что-то web и простое для управления меппингами (типа Apparo FastEdit для Cognos), но с иерархиями там плохо.

Сейчас начинаем сравнивать Orchestra DMX и MDS для одного заказчика, интересно будет посмотреть, насколько плоха Orchestra внутри и насколько хорош стал MDS.
20 фев 17, 06:47    [20227188]     Ответить | Цитировать Сообщить модератору
 Re: Опрос МастерДата  [new]
Roman Kolchin
Member

Откуда:
Сообщений: 188
Юрий Кудрявцев
Сейчас начинаем сравнивать Orchestra DMX и MDS для одного заказчика, интересно будет посмотреть, насколько плоха Orchestra внутри и насколько хорош стал MDS.

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

Что было полезно, когда я внедрял Oracle Data Relationship Management:
- быстрое добавление новых атрибутов без необходимости блокировки справочников;
- контекстно-зависимый состав атрибутов элементов справочников -- возможность варьировать состав и значения атрибутов в зависимости от принадлежности элемента к определенной иерархии (при этом элемент может входить в любое кол-во иерархий), от типа хранения в иерархии (лист/узел верхнего уровня);
- динамические значения атрибутов с возможностью получения различных значений в зависимости от контекста, от взаимного расположения элементов, от переменных среды;
- разграничения доступа на просмотр и редактирование для иерархий, ветвей иерархий, отдельных атрибутов и групп атрибутов;
- транзакционность любых изменений с возможности получения состояния иерархии на любой момент времени и сохранения исторического значения в виде новой иерархии;
- diff, copy-paste, merge межу различными иерархиями и различными версиями одной и той же иерархии;
- экспорт/импорт справочников в виде лога транзакций -- то есть возможность импорта элементов справочников в виде последовательности команд типа "добавить узел", "задать значение свойства X";
- ну и конечно полный Drag-n-Drop и WSWYG с адекватной производительностью для сотен тысяч узлов :)

На момент когда я плотно работал с Oracle DRM этого еще не было, но сейчас есть и имхо это полезный функционал -- процесс внесения изменений внутри mdm-инструмента с возможностью формировать заявки на изменение в виде новых версий иерархий и утверждения изменений с использованием diff/copy-paste/merge. У Oracle'а сейчас для этого используется отдельный модуль -- Oracle Data Relationship Governance.

Еще я не касался вопросов интеграции, поэтому авторитетно сказать, что должно уметь API не скажу. Но Oracle дорабатывает API в _КАЖДОМ_ новом патче. Так что там, очевидно, есть чего развивать.

В материалах с конференций встречал такой кейс использования Oracle DRM:
- бизнес-юезр заходит в DRM, создает "контейнер" — новую мега-иерархию, в котрую закидывает куски существующих иерархий в виде веток от корня;
- после этого пользователь жамкает на кастомную кнопку;
- для пользователя создается куб... да-дам! COGNOS (на тот момент еще не TM1, вроде) и в него загружаются данные в соответствии с выбранными иерархиями.

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

Кстати, про OrchestraNetworks я узнал из внутренних Oracle'вых презентация по DRM -- в них OrchestraNetworks EBX5 была названа основным конкурентом. Это было года четыре назад и тогда ни DRM ни EBX5 не были в Гартнере и их сложно был реально сравнивать.
21 фев 17, 14:22    [20233180]     Ответить | Цитировать Сообщить модератору
 Re: Опрос МастерДата  [new]
No Pasaran
Member

Откуда:
Сообщений: 179
автор
Есть еще удобные инструменты и красивые подходы к решению этих задач?


Посмотрите Ataccama RDM.
17 мар 17, 17:19    [20306945]     Ответить | Цитировать Сообщить модератору
 Re: Опрос МастерДата  [new]
Roman Kolchin
Member

Откуда:
Сообщений: 188
No Pasaran
Посмотрите Ataccama RDM.

Спасибо.
Мб есть презентации или видео с демонстрацией его возможностей? В идеале, чтобы демонстрировали описанный мной функционала.
17 мар 17, 21:32    [20307776]     Ответить | Цитировать Сообщить модератору
 Re: Опрос МастерДата  [new]
Roman Kolchin
Member

Откуда:
Сообщений: 188
У Andrew White, аналитика Gartner'а по теме MDM, вышла статья, описывающая различия в сценариях использования ПО для управления мастер-данными -- Master Data Management (MDM) vs Application Data Management (ADM).

Как оказалось, потребности и задачи, которые я описывал выше в этой теме, да и с которыми я чаще всего сталкивался в различных компаниях, наблюдая их со стороны, относится к области названной Application Data Management (ADM). Это задачи и инструменты, связанные с управлением данными какого-то одного приложения или пакета приложения одной платформы типа ERP или DWH.

Конечно, с чисто технической точки зрения MDM и ADM это игра слов. Но при решении организационных вопросов о запуске проекта, обосновании цены и выборе конкретного программного решения удобно пользователями компактными емкими терминами.

По мнению автора статьи фундаментальное различие между MDM и ADM -- это то, сколько процессов и сколько различных систем завязано на *DM систему. Если много систем и много процессов -- то это MDM, а если одна (или полторы, например одна мега-ERP и пара ее сателлитов) -- это ADM. Отсюда следуют все остальные различия.

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

Функционал MDM в принципе может быть не очень юзер-френдли при условии, что система обеспечивает нужную связанность данных для кучи бизнес-процессов и систем. То есть с убогостью интерфейса можно мириться, если ценность в другом. Тут я вспоминаю MDM HUB'ы от Oracle'а с очень глубокой ритейловой, промышленной и еще рядом узких специализаций, но c совершенно отвратным UX.

С другой стороны система класса ADM обычно выбирается для затыкания "дыр" в функционале какой-то основной системы, типа SAP, Oracle E-Business Suite или платформы аналитических приложений типа Oracle Hyperion или IBM Cognos. В этом случае ценность ADM системы заключается в том, на сколько эффективно затыкаются эти "дыры", поэтому важность хорошего интерфейса пользователя возрастает стократ. Но при этом, тк речь идет об автоматизации всего лишь одной системы или одного бизнес-процесса, то и цена вопроса ожидается существенно ниже, чем у полноценной MDM системы. Собственно, в своей практике я ровно с этим и сталкиваюсь.

Продолжая тему,
уважаемые ALL, вы в своей практике больше сталкивались с системами, или по крайней мере видели потребности в необходимости каких систем, класса *DM: ADM vs MDM.
20 мар 17, 13:04    [20313589]     Ответить | Цитировать Сообщить модератору
 Re: Опрос МастерДата  [new]
essbase.ru
Member

Откуда: http://essbase.ru/about
Сообщений: 1390
Roman Kolchin,

Еще не раскрыта тема работы с натуралкой ) - площадь офиса , расстояние до , и т.д. и т.п.
20 мар 17, 16:04    [20314493]     Ответить | Цитировать Сообщить модератору
 Re: Опрос МастерДата  [new]
Roman Kolchin
Member

Откуда:
Сообщений: 188
essbase.ru
Roman Kolchin,

Еще не раскрыта тема работы с натуралкой ) - площадь офиса , расстояние до , и т.д. и т.п.

Ищи приложения (не MDM) по работе с соответствующими объектами.
20 мар 17, 16:32    [20314712]     Ответить | Цитировать Сообщить модератору
 Re: Опрос МастерДата  [new]
Roman Kolchin
Member

Откуда:
Сообщений: 188
essbase.ru
Roman Kolchin,

Еще не раскрыта тема работы с натуралкой ) - площадь офиса , расстояние до , и т.д. и т.п.

ORACLE SITE HUB
20 мар 17, 17:03    [20314871]     Ответить | Цитировать Сообщить модератору
 Re: Опрос МастерДата  [new]
No Pasaran
Member

Откуда:
Сообщений: 179
автор
Мб есть презентации или видео с демонстрацией его возможностей? В идеале, чтобы демонстрировали описанный мной функционала.


Нашел вот такое видео. [url=][/url]
А вообще если интересно, то могу показать вживую.
23 мар 17, 09:26    [20324032]     Ответить | Цитировать Сообщить модератору
 Re: Опрос МастерДата  [new]
Roman Kolchin
Member

Откуда:
Сообщений: 188
No Pasaran
Нашел вот такое видео.
А вообще если интересно, то могу показать вживую.

Спасибо. Не очень похоже на Hyperion DRM, но вроде почти все что нужно есть.

А какой ценник именно на модуль RDM? Как он лицензируется?

PS. Вживую показывать пока не надо -- прямо сейчас нет задачи под этот инструмент, поэтому не надо тратить время. Но если задача возникнет, то обязательно воспользуюсь предложением :)
26 мар 17, 12:03    [20333564]     Ответить | Цитировать Сообщить модератору
 Re: Опрос МастерДата  [new]
No Pasaran
Member

Откуда:
Сообщений: 179
Лицензируется по числу пользователей. Точные цифры назвать не могу, если будет актуальный интерес, то свяжитесь по контактам на ataccama.ru
27 мар 17, 12:08    [20336390]     Ответить | Цитировать Сообщить модератору
 Re: Опрос МастерДата  [new]
bbx1389
Member

Откуда: Русија
Сообщений: 23935
Roman Kolchin
bbx1389
если шире смотреть, то лучший результат на проектах с запуском централизованного управления НСИ. Т.е. создается специальная служба , ей вменяется в обязанности отвечать за качество\полноту и т.п. данных . Все изменения через заявки в эту службу.

Поясните в чем преимущество такого подхода? Он же ни чем не отличается от классики (не MDM) -- "все клиенты у нас в CRM" или "номенклатура продуктов ведется только в ERP". То есть какой-то домен мастер-данных (набор справочников) ведется в одной системе. Классика даже более качественные данные дает -- в CRM клиентами занимаются специалисты, которые разбираются в отношениях с клиентами, а продукты в ERP ведут люди, разбирающиеся в производственном учете, а универсальные "специалисты НСИ" не пытаются объять все.

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

"номенклатура продуктов ведется только в ERP"
хорошо если у вас одна ERP, а не n с неполностью пересекающимся ассортиментом, например по разным странам. Хорошо когда продуктовых менеджеров не пару десятков, а хотя бы 10, и меняются они не каждый квартал. Атрибутов продукта может быть под сотню. Хорошо, если правила проверки простые и их можно реализовать в программе. Хорошо если бизнес-процессы связанные с отдельными атрибутами , хотя бы можно диаграммой на 1 листе описать. Ну и т.д.

"продукты в ERP ведут люди, разбирающиеся в производственном учете" -это кто?
3 апр 17, 12:20    [20360384]     Ответить | Цитировать Сообщить модератору
 Re: Опрос МастерДата  [new]
Roman Kolchin
Member

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

Вы как раз утверждаете, что это лучший подход :) Вы же перечислили просто сказочные преимущества. Если все так как вы утверждаете, то я даже не представляю какой еще подход сможет дать аналогичный результат :)
Вопрос в том "за счет чего"? За счет чего все получается дешево и очень эффективно с использованием выделенной группы НСИ? Вы это не пояснили.

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

Где здесь дешевизна и эффективность?

bbx1389
"номенклатура продуктов ведется только в ERP"
хорошо если у вас одна ERP, а не n с неполностью пересекающимся ассортиментом, например по разным странам. Хорошо когда продуктовых менеджеров не пару десятков, а хотя бы 10, и меняются они не каждый квартал. Атрибутов продукта может быть под сотню. Хорошо, если правила проверки простые и их можно реализовать в программе. Хорошо если бизнес-процессы связанные с отдельными атрибутами , хотя бы можно диаграммой на 1 листе описать. Ну и т.д.

"продукты в ERP ведут люди, разбирающиеся в производственном учете" -это кто?

"продукты в ERP ведут люди, разбирающиеся в производственном учете" -- это люди, которые разбираются в соответствующих бизнес-процессах и их данных в ERP. Если имеем дело с одной ERP, то это люди связанные с этой ERP, если ERP несколько -- то люди из разных ERP.

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

Собственно, весь западный рынок MDM построен на идее дать разным людям общий инструмент управления разделяемыми данными.
3 апр 17, 13:19    [20360601]     Ответить | Цитировать Сообщить модератору
 Re: Опрос МастерДата  [new]
Kuel
Member

Откуда:
Сообщений: 2
No Pasaran
HF, конечно, неплохой продукт. Главный вопрос - это стоимость его долгосрочного владения. Это же черный ящик, который заказчик сам не может никак подкрутить, надо все время листать HF. А DQ\MDM - это как ХД, тут нельзя один раз купить коробку и нажать install.exe, все время нужно что-то подкручивать. Можно на госзакупках легко посмотреть сколько десятков миллионов сбер платить в год за поддержку HF и все станет ясно.

Ну и по адресам, конечно, HF совсем не монополист. Во-первых, явно лучше качество работы с российскими адресами у IQ systems, а Ataccama проигрывает HF всего 1-2% при разборе адресов. Если сравнивать HF с AddressDoctor, то, тут конечно, да разница - небо и земля.

Всем здравствуйте!
Хотелось бы узнать мнение об эффективности использования AddressDoctor для проверки российских адресов.
Мы планируем купить этот продукт с целью проверки вводимых адресов клиентов на нашем сайт.

Если честно не понял в сообщении No Pasaran, что лучше HF или AddressDoctor.
20 окт 17, 11:43    [20885237]     Ответить | Цитировать Сообщить модератору
 Re: Опрос МастерДата  [new]
No Pasaran
Member

Откуда:
Сообщений: 179
Adressdoctor -для россии полный аццтой. Hf по сравнению с ним на порядок сильнее. Еще есть iq systems, результат дает даже лучше hf по нашим тестам.
21 окт 17, 22:30    [20889122]     Ответить | Цитировать Сообщить модератору
 Re: Опрос МастерДата  [new]
Kuel
Member

Откуда:
Сообщений: 2
No Pasaran,
Спасибо , к сожалению в моей компании выбрали AddressDoctor для всех стран и не мне решать в пользу других программ.
24 окт 17, 15:49    [20895968]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3]      все
Все форумы / OLAP и DWH Ответить