#проITсистемы #mdm #мойопыт #капитаночевидность #мирвокруг
Про MDM - системы
Так, так, так, обещала писать про классы информационных систем и замоталась. 🙈 Исправляюсь!
Сегодня про MDM - системы, то есть Master Data Management, а не Московский дом молодежи 😂
Или система управления мастер-данными. Что же такое мастер-данные? Это бизнес-критичные данные. Какие такие критичные?) Данные о том, что нам приносит деньги. Если бы говорим про b2c, это конечно данные о клиентах, и всё вокруг их, если b2b может быть, что угодно персонал, материалы, производство и т.п.
В основе лежат данные об объектах бизнеса и вокруг них справочные данные, которые помогают описывать объекты.
Почему я от CRM перешла к MDM? Да потому что CRM нам даёт возможность выстраивать отношения с клиентами, а MDM хранить эталонные данные о клиентах.
Эволюция пошла в сторону MDM систем, по причине того, что данные о клиентах начали размазываться по всем ИТ-системам в ландшафте компании и в какой-то момент бизнес, по отчётам из той же CRM, не смогли принимать решения. Данные с большой погрешностью. И часто в компаниях возникают ситуации, когда даже посчитать количество клиентов невозможно, происходит задвоение, затроение.
Тут как раз и помогает MDM-система, которая не только собирает и накапливает данные о клиентах, но и очищает их, запуская процессы проверки наличия задвоения или затроения. Но это ещё не всё! В MDM-системах есть механизм выверки данных за счёт алгоритмов! Приведу пример работы одного из алгоритмов. Например, я звоню в колл-центр, и меня спрашивают ваше имя, я говорю Натася)))) Или просто оператор опечатался, и бабац вроде как должен появиться новый клиент Натася, живущий, например, в МАскве, по улице тардовского))) Алгоритмы MDM системы, поймут, что я Наташа из Москвы с улицы Твардовского. Поищут мою карточку, и убьют непонятные данные и пропишут все нужные связи со справочной информацией, в том числе и с КЛАДР. То есть мы получим эталонные данные по клиенту. Вжух и магия!!!
Мой любимый вопрос архитекторам, чем MDM система отличается от обычной учётной системы, или от хранилища так называемого НСИ? Ключевое отличие, это как раз наличие механизмов чистки данных, их выверки и развития умных алгоритмов. Обычная учетка, просто собирает, складирует, обновляет и раздаёт данные. А на что это всё похоже?))) Конечно на интеграционную шину. Не прямо конечно, а косвенно. Шина всё таки должна получить, обогатить, или изменить данные и передать. А MDM становится центром для всех других систем, раздаёт и принимает данные.
Когда я изучала тему рынка MDM систем, увидела такую штуку, что многие из них выросли как раз из интеграционных решений, например Talend MDM. Душе внутри Talend по своей админке напоминает интеграцию. Я не могу экспертно говорить о лидерах MDM решений, скажу то, что многие организации не понимают зачем они нужны им? И роют себе яму на самом старте, когда не только не собирают данные, но и не чистят их. Но при этом покупают крутые движки для отчётов))) А то что такие отчёты будут показывать информацию с большой погрешностью, мало кто думает, только на зрелом этапе развития компании, появляется подобная потребность. Если говорить про b2b, то часто заказчик, особенно госзаказчик не понимает зачем им MDM, им и справочников с учёткой вполне достаточно)
Но! Это кстати крутой показатель! 1С в своей линейке продуктов имеет MDM! Каково)))
Про MDM - системы
Так, так, так, обещала писать про классы информационных систем и замоталась. 🙈 Исправляюсь!
Сегодня про MDM - системы, то есть Master Data Management, а не Московский дом молодежи 😂
Или система управления мастер-данными. Что же такое мастер-данные? Это бизнес-критичные данные. Какие такие критичные?) Данные о том, что нам приносит деньги. Если бы говорим про b2c, это конечно данные о клиентах, и всё вокруг их, если b2b может быть, что угодно персонал, материалы, производство и т.п.
В основе лежат данные об объектах бизнеса и вокруг них справочные данные, которые помогают описывать объекты.
Почему я от CRM перешла к MDM? Да потому что CRM нам даёт возможность выстраивать отношения с клиентами, а MDM хранить эталонные данные о клиентах.
Эволюция пошла в сторону MDM систем, по причине того, что данные о клиентах начали размазываться по всем ИТ-системам в ландшафте компании и в какой-то момент бизнес, по отчётам из той же CRM, не смогли принимать решения. Данные с большой погрешностью. И часто в компаниях возникают ситуации, когда даже посчитать количество клиентов невозможно, происходит задвоение, затроение.
Тут как раз и помогает MDM-система, которая не только собирает и накапливает данные о клиентах, но и очищает их, запуская процессы проверки наличия задвоения или затроения. Но это ещё не всё! В MDM-системах есть механизм выверки данных за счёт алгоритмов! Приведу пример работы одного из алгоритмов. Например, я звоню в колл-центр, и меня спрашивают ваше имя, я говорю Натася)))) Или просто оператор опечатался, и бабац вроде как должен появиться новый клиент Натася, живущий, например, в МАскве, по улице тардовского))) Алгоритмы MDM системы, поймут, что я Наташа из Москвы с улицы Твардовского. Поищут мою карточку, и убьют непонятные данные и пропишут все нужные связи со справочной информацией, в том числе и с КЛАДР. То есть мы получим эталонные данные по клиенту. Вжух и магия!!!
Мой любимый вопрос архитекторам, чем MDM система отличается от обычной учётной системы, или от хранилища так называемого НСИ? Ключевое отличие, это как раз наличие механизмов чистки данных, их выверки и развития умных алгоритмов. Обычная учетка, просто собирает, складирует, обновляет и раздаёт данные. А на что это всё похоже?))) Конечно на интеграционную шину. Не прямо конечно, а косвенно. Шина всё таки должна получить, обогатить, или изменить данные и передать. А MDM становится центром для всех других систем, раздаёт и принимает данные.
Когда я изучала тему рынка MDM систем, увидела такую штуку, что многие из них выросли как раз из интеграционных решений, например Talend MDM. Душе внутри Talend по своей админке напоминает интеграцию. Я не могу экспертно говорить о лидерах MDM решений, скажу то, что многие организации не понимают зачем они нужны им? И роют себе яму на самом старте, когда не только не собирают данные, но и не чистят их. Но при этом покупают крутые движки для отчётов))) А то что такие отчёты будут показывать информацию с большой погрешностью, мало кто думает, только на зрелом этапе развития компании, появляется подобная потребность. Если говорить про b2b, то часто заказчик, особенно госзаказчик не понимает зачем им MDM, им и справочников с учёткой вполне достаточно)
Но! Это кстати крутой показатель! 1С в своей линейке продуктов имеет MDM! Каково)))
#мирвокруг #мойопыт #интеграция #проITсистемы
Как и обещала сегодня поговорим про Интеграционные решения.
Начнем с этимологии термина.
Интегра́ция (от лат. integratio — «восстановление», «восполнение», «соединение») — процесс объединения частей в целое.
От наших политиков можно часто услышать термин интеграция, но и в АйТи без него никак, потому что АйТи ландшафт компании постоянно меняется, что-то появляется новое, что-то исчезает.
Суть Интеграции - это объединение информационных систем в общую структуру.
Раз вопрос звучал "что такое шина?", то я решила разобрать классификацию интеграционных решений по типу топологии сетей. Получилась смесь моих мыслей и фундаментальных объяснений, которые можно найти в исследовательских статьях в интернете.
Можно выделить три типа построения решений интеграции:
Точка-точка
Децентрализованное соединение точка-точка означает, что интегрируемые информационные системы устанавливают прямые связи друг с другом. Такой способ интеграции простой, понятный, и работает “без посредника”, передача данных происходит напрямую от одной системы в другую. Часто используется на начальных этапах построения информационного ландшафта компании (стартап), либо как запасное решение (work around) для ускорения процесса.
Минус такого решения - это рост количества связей, чем больше точек соединения, тем больше связей (рост количества новых интерфейсов растет по формуле n (n–1), где n — число участников интеграции), что приводит к повышению трудоёмкости поддержки и внесения изменений.
Шлюз
Чтобы уменьшить количество связей между участниками интеграции (до 2n), а также повысить надежность интеграционного решения применяют модули взаимодействия на основе централизованного шлюза (рис. 1,б) или шины (рис. 1,в).
Модели интеграции на основе шлюза и шины относятся к классу программного обеспечения промежуточного уровня (middleware), обеспечивающего трансформацию, транспортировку, маршрутизацию данных. Поэтому часто можно услышать спор среди архитекторов - насчёт того, что на шлюзе/шине не должно быть бизнес-логики обработки данных, предназначение такого рода решений является именно передача данных и их минимальная трансформация.
Шлюз или централизованный брокер возникает как центральный узел, к которому обращаются интегрируемые системы и приложения, то есть по сути представляет собой маршрутизатор сообщений. Через него направляются потоки сообщений и данных с этих систем. Шлюз перераспределяет, обрабатывает и направляет такие потоки. Использование шлюза позволяет возложить на него функции адресации и трансформации передаваемых данных, причем гораздо более сложные, чем в случае прямого соединения или применения адаптеров. Централизованная реализация функций обработки передаваемой информации и данных ведет к выделению репозитория общих интеграционных правил, что позволяет эффективно и динамически сопрягать приложения в единую среду.
Каналы, которые образуют шлюз, можно разделить на внешние и внутренние. Они могут быть реализованы по одному и тому же протоколу, в таком случае шлюз используется на шине, в качестве составной части шины с целью разбиения шины на сегменты для обеспечения отказоустойчивости или защищенности каналов (пример, это копирование шлюза при распределенной филиальной системы предприятия, для каждого филиала поддерживается свой шлюз).
Шина
Топология шина - это когда приложения используют многочисленные подсоединения к единой среде обмена информацией. Топология шины является более гибкой, чем централизованный шлюз, и не имеет единой критической для сбоев и производительности точки. В то же время реализация топологии типа шины часто предусматривает более жесткую спецификацию внутренних форматов и данных, которыми обмениваются через шину взаимодействующие приложения и тем самым накладывает определенные ограничения.
Продолжение 👇
Как и обещала сегодня поговорим про Интеграционные решения.
Начнем с этимологии термина.
Интегра́ция (от лат. integratio — «восстановление», «восполнение», «соединение») — процесс объединения частей в целое.
От наших политиков можно часто услышать термин интеграция, но и в АйТи без него никак, потому что АйТи ландшафт компании постоянно меняется, что-то появляется новое, что-то исчезает.
Суть Интеграции - это объединение информационных систем в общую структуру.
Раз вопрос звучал "что такое шина?", то я решила разобрать классификацию интеграционных решений по типу топологии сетей. Получилась смесь моих мыслей и фундаментальных объяснений, которые можно найти в исследовательских статьях в интернете.
Можно выделить три типа построения решений интеграции:
Точка-точка
Децентрализованное соединение точка-точка означает, что интегрируемые информационные системы устанавливают прямые связи друг с другом. Такой способ интеграции простой, понятный, и работает “без посредника”, передача данных происходит напрямую от одной системы в другую. Часто используется на начальных этапах построения информационного ландшафта компании (стартап), либо как запасное решение (work around) для ускорения процесса.
Минус такого решения - это рост количества связей, чем больше точек соединения, тем больше связей (рост количества новых интерфейсов растет по формуле n (n–1), где n — число участников интеграции), что приводит к повышению трудоёмкости поддержки и внесения изменений.
Шлюз
Чтобы уменьшить количество связей между участниками интеграции (до 2n), а также повысить надежность интеграционного решения применяют модули взаимодействия на основе централизованного шлюза (рис. 1,б) или шины (рис. 1,в).
Модели интеграции на основе шлюза и шины относятся к классу программного обеспечения промежуточного уровня (middleware), обеспечивающего трансформацию, транспортировку, маршрутизацию данных. Поэтому часто можно услышать спор среди архитекторов - насчёт того, что на шлюзе/шине не должно быть бизнес-логики обработки данных, предназначение такого рода решений является именно передача данных и их минимальная трансформация.
Шлюз или централизованный брокер возникает как центральный узел, к которому обращаются интегрируемые системы и приложения, то есть по сути представляет собой маршрутизатор сообщений. Через него направляются потоки сообщений и данных с этих систем. Шлюз перераспределяет, обрабатывает и направляет такие потоки. Использование шлюза позволяет возложить на него функции адресации и трансформации передаваемых данных, причем гораздо более сложные, чем в случае прямого соединения или применения адаптеров. Централизованная реализация функций обработки передаваемой информации и данных ведет к выделению репозитория общих интеграционных правил, что позволяет эффективно и динамически сопрягать приложения в единую среду.
Каналы, которые образуют шлюз, можно разделить на внешние и внутренние. Они могут быть реализованы по одному и тому же протоколу, в таком случае шлюз используется на шине, в качестве составной части шины с целью разбиения шины на сегменты для обеспечения отказоустойчивости или защищенности каналов (пример, это копирование шлюза при распределенной филиальной системы предприятия, для каждого филиала поддерживается свой шлюз).
Шина
Топология шина - это когда приложения используют многочисленные подсоединения к единой среде обмена информацией. Топология шины является более гибкой, чем централизованный шлюз, и не имеет единой критической для сбоев и производительности точки. В то же время реализация топологии типа шины часто предусматривает более жесткую спецификацию внутренних форматов и данных, которыми обмениваются через шину взаимодействующие приложения и тем самым накладывает определенные ограничения.
Продолжение 👇
#проITсистемы #интеграция #мойопыт #мирвокруг
Начало 👆
Интеграционная шина - это прежде всего среда передачи сообщений, позволяющая доставлять сообщения на основе логических признаков. "На пальцах", это означает, что в самих сообщениях не содержатся никакие физические адреса.
Простейшие варианты интеграционных шин держат у себя справочник соответствия логических и физических адресов. Логические адреса формируются исходя из назначения приложения, его названия или оргструктуры. Более сложные варианты дают возможность доставки сообщений по системе pub/sub (публикатор - подписчик).
Интеграционная шина может быть построена вокруг центрального узла (или нескольких узлов), где "крутится" маршрутизатор - или же быть распределенной, существуя в виде кучи адаптеров (которые поддерживают преобразование данных в формат шины) на стороне каждого приложения с общей базой адресов.
Шины, которые часто встречаются в компаниях (с которыми я лично работала):
✔️IBM WebSphere
✔️Oracle Service Bus
✔️CBoss - компания, которые делала решения для телеком компаний и у неё было оперсорс решение для интеграции.
✔️GlassFish - также было опенсорс.
Интеграция большая тема и тянет на отдельную статью, поэтому продолжение следует)
Картинку и немного слов взяла из статьи https://cyberleninka.ru/article/n/modeli-integratsionnyh-resheniy-na-predpriyatii-i-ih-nadezhnost
Начало 👆
Интеграционная шина - это прежде всего среда передачи сообщений, позволяющая доставлять сообщения на основе логических признаков. "На пальцах", это означает, что в самих сообщениях не содержатся никакие физические адреса.
Простейшие варианты интеграционных шин держат у себя справочник соответствия логических и физических адресов. Логические адреса формируются исходя из назначения приложения, его названия или оргструктуры. Более сложные варианты дают возможность доставки сообщений по системе pub/sub (публикатор - подписчик).
Интеграционная шина может быть построена вокруг центрального узла (или нескольких узлов), где "крутится" маршрутизатор - или же быть распределенной, существуя в виде кучи адаптеров (которые поддерживают преобразование данных в формат шины) на стороне каждого приложения с общей базой адресов.
Шины, которые часто встречаются в компаниях (с которыми я лично работала):
✔️IBM WebSphere
✔️Oracle Service Bus
✔️CBoss - компания, которые делала решения для телеком компаний и у неё было оперсорс решение для интеграции.
✔️GlassFish - также было опенсорс.
Интеграция большая тема и тянет на отдельную статью, поэтому продолжение следует)
Картинку и немного слов взяла из статьи https://cyberleninka.ru/article/n/modeli-integratsionnyh-resheniy-na-predpriyatii-i-ih-nadezhnost
КиберЛенинка
Модели интеграционных решений на предприятии и их надежность
Рассмотрены модели интеграционных решений точка-точка, централизованный шлюз, шина корпоративных сервисов (point-to-point, hub-and-spoke, enterprise service bus). Исследована надежность данных моделей по критерию вероятности безотказной работы информационной…
#мирвокруг #мойопыт #интеграция #проITсистемы
Вчера у меня получился большой и сложный пост, поэтому я сегодня сделаю небольшой шаг назад и попытаюсь рассказать попроще.
Любое интеграционное решение служит для выполнения четырех главных технологических функций:
✔️подключение к интеграционной среде,
✔️транспортировка,
✔️трансформация данных,
✔️процессы обработки.
Если говорить про кровавый enterprise, то тут можно с разных сторон смотреть на интеграцию.
С точки зрения бизнеса, Интеграция может быть реализована для бизнес-процессоров, сначала мы "склеиваем" цепочку из шагов, а потом уже принимаем решение, как её реализовать на уровне функций и систем. Но также Интеграция может быть реализована по данным, когда реализуется обмен справочниками.
Далее классификация решений может быть реализована согласно топологии сети. О чём я вчера писала.
И ещё я бы ввела классификацию по способу передачи информации. Сюда можно добавить интеграцию с помощью файлового обмена, прямых обращений в БД, очередей и онлайн обмен (вроде ничего не забыла).
Вчера справедливо было замечено, что я не написала про Брокер.
Сегодня восполняю этот пробел.
Интеграционные брокеры обеспечивают взаимодействие приложений через центральный промежуточный шлюз, поддерживающий интеллектуальную обработку и распределение данных между приложениями. Роль брокера в интеграционной среде, основанной на передаче сообщений, — это роль почтамта, сортирующего и регистрирующего почтовые отправления, проверяющего адресную информацию и распределяющего их для дальнейшей отправки адресатам.
Брокер возникает как промежуточный сервер в интеграционной транспортной среде и занимается обработкой потоков сообщений и передаваемых данных, а также исполнением вызовов и обращения по различным интерфейсам. Брокер перераспределяет, обрабатывает и направляет потоки информации, данных и сообщений между интегрируемыми системами.
Из решений, которые сейчас очень популярны это конечно rabbitMQ и
IBM MQ Message Broker.
На практике Message Queue Broker распределял сообщения между интегрируемыми системами с помощью очередей сообщений, именно такая схема изображена на рисунке.
Часто происходит смешение понятий и можно встретить шлюз, который будет реализован на шине. Или интеграцию построенную на очередях, про которую также будут говорить, что это шина. И как мне кажется, слово шина стала таким понятием нарицательным, что многие и не задумываются о том, что лежит в основе.
В завершение темы интеграции скажу, что часто на собеседованиях встречаю вопросы именно про интеграцию. Про типы решений, про способы передачи данных и различные задачи по выстраиванию обмена данных через интеграцию.
Интеграцию люблю, потому что это способ увидеть изнутри все процессы компании через соединения различных АйТи систем.
Ссылки на источники:
https://cyberleninka.ru/article/n/ш17264282
http://mqseries.narod.ru/book/webspheremq_12.htm
https://www.osp.ru/os/2003/09/183373
https://habr.com/ru/post/326088/
Вчера у меня получился большой и сложный пост, поэтому я сегодня сделаю небольшой шаг назад и попытаюсь рассказать попроще.
Любое интеграционное решение служит для выполнения четырех главных технологических функций:
✔️подключение к интеграционной среде,
✔️транспортировка,
✔️трансформация данных,
✔️процессы обработки.
Если говорить про кровавый enterprise, то тут можно с разных сторон смотреть на интеграцию.
С точки зрения бизнеса, Интеграция может быть реализована для бизнес-процессоров, сначала мы "склеиваем" цепочку из шагов, а потом уже принимаем решение, как её реализовать на уровне функций и систем. Но также Интеграция может быть реализована по данным, когда реализуется обмен справочниками.
Далее классификация решений может быть реализована согласно топологии сети. О чём я вчера писала.
И ещё я бы ввела классификацию по способу передачи информации. Сюда можно добавить интеграцию с помощью файлового обмена, прямых обращений в БД, очередей и онлайн обмен (вроде ничего не забыла).
Вчера справедливо было замечено, что я не написала про Брокер.
Сегодня восполняю этот пробел.
Интеграционные брокеры обеспечивают взаимодействие приложений через центральный промежуточный шлюз, поддерживающий интеллектуальную обработку и распределение данных между приложениями. Роль брокера в интеграционной среде, основанной на передаче сообщений, — это роль почтамта, сортирующего и регистрирующего почтовые отправления, проверяющего адресную информацию и распределяющего их для дальнейшей отправки адресатам.
Брокер возникает как промежуточный сервер в интеграционной транспортной среде и занимается обработкой потоков сообщений и передаваемых данных, а также исполнением вызовов и обращения по различным интерфейсам. Брокер перераспределяет, обрабатывает и направляет потоки информации, данных и сообщений между интегрируемыми системами.
Из решений, которые сейчас очень популярны это конечно rabbitMQ и
IBM MQ Message Broker.
На практике Message Queue Broker распределял сообщения между интегрируемыми системами с помощью очередей сообщений, именно такая схема изображена на рисунке.
Часто происходит смешение понятий и можно встретить шлюз, который будет реализован на шине. Или интеграцию построенную на очередях, про которую также будут говорить, что это шина. И как мне кажется, слово шина стала таким понятием нарицательным, что многие и не задумываются о том, что лежит в основе.
В завершение темы интеграции скажу, что часто на собеседованиях встречаю вопросы именно про интеграцию. Про типы решений, про способы передачи данных и различные задачи по выстраиванию обмена данных через интеграцию.
Интеграцию люблю, потому что это способ увидеть изнутри все процессы компании через соединения различных АйТи систем.
Ссылки на источники:
https://cyberleninka.ru/article/n/ш17264282
http://mqseries.narod.ru/book/webspheremq_12.htm
https://www.osp.ru/os/2003/09/183373
https://habr.com/ru/post/326088/
Продолжаем тему #проITсистемы #мирвокруг #пополочкам #мойопыт
Сегодня поговорим про #биллинг
Итак, биллинг - от слова bill, с английского, счёт или billing - выставление счетов. То есть это класс прикладных информационных систем, которые отвечают за сбор информации об оказанных услугах абонентам (я тут не отпечаталась, потому что биллинговые системы и тарифы встречаются прежде всего в телеком среде) и выставляют счёта, за эти самые услуги. Эдакий умный калькулятор))
Если говорить про телеком, то тарификация у нас есть prepaid (положил на счёт деньги и пользуешься услугами) и postpaid (сначала пользуешься, потом платишь). То что я видела в телеком среде, это две разные системы, одна рассчитывает по prepaid, другая по postpaid. Как-то мне довелось настраивать тарифы в одной из биллинговых систем, мозг мой был взорван! И это мягко сказано))
Помощь, что визуально тариф представлял собой большое дерево с кучей разных настроек. Это всё что я помню)))
Что для меня, как для аналитика означала интеграция с биллингом? Прежде всего это активация и деактивация услуг, тарифов и всего, за что телеком оператор снимал деньги с абонента, фактически управление балансом.
Ещё биллинг я встречала в страхование и у провайдеров. В страховой существовали схемы оплаты полиса сразу полная сумма, или в рассрочку, или в кредит. Поэтому в страхование нужно было не только зафиксировать id проданного полиса, но и прописать по какой схеме клиент будет проводить оплату. Также биллинг вёл список должников, занимался процессами защиты от мошенников, посылал рассылку о блокировке клиента, выставлял счета и фиксировал их оплату.
То есть в составе биллинга может быть включены подсистемы оповещения, преобразования данных, безопасности.
Везде, где есть сложные схемы расчёта с клиентами, есть биллинг.
Из систем, которые я помню, это была система фирмы Comverse в телеком, а в страховой был отдельный продукт из линейки компании Guidewire - Billing Center.
Если встречали другие названия на практике, пишите в комментариях, будет интересно посмотреть)
Сегодня поговорим про #биллинг
Итак, биллинг - от слова bill, с английского, счёт или billing - выставление счетов. То есть это класс прикладных информационных систем, которые отвечают за сбор информации об оказанных услугах абонентам (я тут не отпечаталась, потому что биллинговые системы и тарифы встречаются прежде всего в телеком среде) и выставляют счёта, за эти самые услуги. Эдакий умный калькулятор))
Если говорить про телеком, то тарификация у нас есть prepaid (положил на счёт деньги и пользуешься услугами) и postpaid (сначала пользуешься, потом платишь). То что я видела в телеком среде, это две разные системы, одна рассчитывает по prepaid, другая по postpaid. Как-то мне довелось настраивать тарифы в одной из биллинговых систем, мозг мой был взорван! И это мягко сказано))
Помощь, что визуально тариф представлял собой большое дерево с кучей разных настроек. Это всё что я помню)))
Что для меня, как для аналитика означала интеграция с биллингом? Прежде всего это активация и деактивация услуг, тарифов и всего, за что телеком оператор снимал деньги с абонента, фактически управление балансом.
Ещё биллинг я встречала в страхование и у провайдеров. В страховой существовали схемы оплаты полиса сразу полная сумма, или в рассрочку, или в кредит. Поэтому в страхование нужно было не только зафиксировать id проданного полиса, но и прописать по какой схеме клиент будет проводить оплату. Также биллинг вёл список должников, занимался процессами защиты от мошенников, посылал рассылку о блокировке клиента, выставлял счета и фиксировал их оплату.
То есть в составе биллинга может быть включены подсистемы оповещения, преобразования данных, безопасности.
Везде, где есть сложные схемы расчёта с клиентами, есть биллинг.
Из систем, которые я помню, это была система фирмы Comverse в телеком, а в страховой был отдельный продукт из линейки компании Guidewire - Billing Center.
Если встречали другие названия на практике, пишите в комментариях, будет интересно посмотреть)
#проITсистемы #пополочкам #mdm #etl #мирвокруг
Очень крутой комментарий был мне написан под постом про MDM- системы, что мол есть же еще ETL. Я задумалась, да так сильно, что как типичный аналитик пошла спрашивать своих знакомых экспертов-архитекторов, и читать статьи. Что же из этого получилось?)))
Итак, предлагаю разобраться в понятие ETL - расшифровка на английском Extract, Transform, Load - то есть, извлечение, преобразование, загрузка. Это системы, которые обеспечивают транспорт к хранилищу компании. ETL-процесс это термин, который приходит из Business Intelligence среды, и помогает в сборе и очистки данных для создания аналитической базы данных.
Всё очень похоже по описанию с MDM системой, и всё крутится вокруг интеграции, чем меня сильно путает)))
В англоговорящих источниках различие между ETL и MDM описывают с точки зрения целей. Что да, они могут друг друга дополнять, и ETL можно использовать как механизм доставки и преобразования информации, а MDM как механизм создания эталонной записи, дедупликация, версионирование данных, то есть первые за данные с точки зрения транспорта и очистки, а вторые с точки зрения бизнеса и логики. То есть получается, что и MDM и ETL участвуют в создание EIM - Enterprise Information Management- управление корпоративной информацией.
Уж не знаю, что появилось раньше, но похоже, что ETL как основной механизм работы с данными, далее его стало не хватать и пришел на помощь MDM, который при коллизиях информации спрашивает у человека, как поступать с эталонной "золотой" записью?
Картинка, которая мне понравилась показывает эволюцию хранилищ, где ETL есть и есть Data Quality Management, но потом появляется и MDM.
Источники:
Картинка вот отсюда - https://otr.ru/projects/univ/mdm/
https://chernobrovov.ru/articles/etl-chto-takoe-zachem-i-dlya-kogo.html
https://sourceforge.net/software/compare/Informatica-MDM-vs-SDTM-ETL/
https://www.cmswire.com/cms/information-management/forrester-links-structured-and-unstructured-information-in-new-eim-framework-021868.php
https://blog.semarchy.com/etl-vs-mdm
Очень крутой комментарий был мне написан под постом про MDM- системы, что мол есть же еще ETL. Я задумалась, да так сильно, что как типичный аналитик пошла спрашивать своих знакомых экспертов-архитекторов, и читать статьи. Что же из этого получилось?)))
Итак, предлагаю разобраться в понятие ETL - расшифровка на английском Extract, Transform, Load - то есть, извлечение, преобразование, загрузка. Это системы, которые обеспечивают транспорт к хранилищу компании. ETL-процесс это термин, который приходит из Business Intelligence среды, и помогает в сборе и очистки данных для создания аналитической базы данных.
Всё очень похоже по описанию с MDM системой, и всё крутится вокруг интеграции, чем меня сильно путает)))
В англоговорящих источниках различие между ETL и MDM описывают с точки зрения целей. Что да, они могут друг друга дополнять, и ETL можно использовать как механизм доставки и преобразования информации, а MDM как механизм создания эталонной записи, дедупликация, версионирование данных, то есть первые за данные с точки зрения транспорта и очистки, а вторые с точки зрения бизнеса и логики. То есть получается, что и MDM и ETL участвуют в создание EIM - Enterprise Information Management- управление корпоративной информацией.
Уж не знаю, что появилось раньше, но похоже, что ETL как основной механизм работы с данными, далее его стало не хватать и пришел на помощь MDM, который при коллизиях информации спрашивает у человека, как поступать с эталонной "золотой" записью?
Картинка, которая мне понравилась показывает эволюцию хранилищ, где ETL есть и есть Data Quality Management, но потом появляется и MDM.
Источники:
Картинка вот отсюда - https://otr.ru/projects/univ/mdm/
https://chernobrovov.ru/articles/etl-chto-takoe-zachem-i-dlya-kogo.html
https://sourceforge.net/software/compare/Informatica-MDM-vs-SDTM-ETL/
https://www.cmswire.com/cms/information-management/forrester-links-structured-and-unstructured-information-in-new-eim-framework-021868.php
https://blog.semarchy.com/etl-vs-mdm
Chernobrovov.ru
ETL: что такое, зачем и для кого - Алексей Чернобровов
#мойопыт #проITсистемы #ERP #мысливслух #мирвокруг #пополочкам
Про ERP - системы.
Дословный перевод Enterprise Resource Planning - планирование ресурсов предприятия.
Немного о своём опыте. Как там в сказках, давным давно меня на одном из собеседований спросили, работала ли я с ERP и что я о них знаю. Тогда я не работала с автоматизацией предприятий и не могла понять, как этот пункт может повлиять на выбор моей кандидатуры. Спустя годы, могу сказать, что конечно опыт работы с предприятиями нужен и понимать как работает предприятие и интересно, и нужно.
В основе лежат бизнес-процессы предприятия и методология, если мы говорим, например, про промышленность. И тут можно быть супер крутым аналитиком, но до конца не понимать нюансы на том уровне, на котором работают эксперты.
Что же, с моей точки зрения, из себя представляет ERP? Это целый комплекс информационных систем соединённых в один организм. В основе лежат конечно же данные о ресурсах предприятия, которые необходимы для выполнения работ. И информация о ресурсах, как кровь по сосудам, перетекает из одной информационной системы в другую. Ещё одна аналогия это пазл. ERP сейчас собирается из модулей как пазл, для предприятия.
Вцелом, все предыдущие классы информационных систем, о которых я писала, можно встретить в комплексе ERP. Что главное? Это учёт ресурсов, их планирование, выводы, то есть отчётность, чтобы сделать новый цикл планирования с учётом ошибок, рисков и проблем на предприятии.
Если говорить про промышленность, а мы ещё живём в России, то стоит проследить за историей развития отрасли. Сталин, пятилетки, промышленная революция. Конечно предприятия изменились за годы, но в основе, в фундаменте, будут именно те процессы, которые были заложены в самом начале. И да, от предприятия к предприятию они шаблонные, отличия могут вносить только специфика отрасли.
Чтобы понять модули ERP, предлагаю пройтись по цепочке процессов. Рассмотрим самое простое. У нас например больница, и есть диспетчер и сантехники. Ежемесячно диспетчер планирует работу сантехников. Обход больницы, обход операционных, например 2 раза в день. И какой-то набор запчастей, который должен быть ежемесячно. Если его не хватает, диспетчер делает запрос на склад, склад делает запрос в бухгалтерию, та всё оплачивает, потом оно поступает на склад. Что может пойти не так? Авария. Тут есть бригада и она экстренно должна реагировать и также у неё должен быть набор запчастей. А если больница большая, то ещё машина и бензин, например. Если говорить про автоматизацию, то тут процесс планирования- эксплуатации, работа склада, Интеграция с бухгалтерией и работа диспетчера с сантехниками, фиксирование задач, их приоритет и исполнение - отчётность о проведенных работах и далее новый цикл. И конечно управление сотрудниками, модуль HR, как без него.
Нюансы - это контекст предприятия, больница, операционная или обычная палата, тут и приоритет совсем другой у вызова сантехника и его задачи.
Я конечно всё очень упрощённо описала, но суть именно такая. И модули планирования, отчётности, хранилища данных и исполнения задач вы найдете на любом предприятии.
Самая знаменитая ERP система, это конечно SAP, в России есть 1С, и решения для каждой отрасли свои.
Про ERP - системы.
Дословный перевод Enterprise Resource Planning - планирование ресурсов предприятия.
Немного о своём опыте. Как там в сказках, давным давно меня на одном из собеседований спросили, работала ли я с ERP и что я о них знаю. Тогда я не работала с автоматизацией предприятий и не могла понять, как этот пункт может повлиять на выбор моей кандидатуры. Спустя годы, могу сказать, что конечно опыт работы с предприятиями нужен и понимать как работает предприятие и интересно, и нужно.
В основе лежат бизнес-процессы предприятия и методология, если мы говорим, например, про промышленность. И тут можно быть супер крутым аналитиком, но до конца не понимать нюансы на том уровне, на котором работают эксперты.
Что же, с моей точки зрения, из себя представляет ERP? Это целый комплекс информационных систем соединённых в один организм. В основе лежат конечно же данные о ресурсах предприятия, которые необходимы для выполнения работ. И информация о ресурсах, как кровь по сосудам, перетекает из одной информационной системы в другую. Ещё одна аналогия это пазл. ERP сейчас собирается из модулей как пазл, для предприятия.
Вцелом, все предыдущие классы информационных систем, о которых я писала, можно встретить в комплексе ERP. Что главное? Это учёт ресурсов, их планирование, выводы, то есть отчётность, чтобы сделать новый цикл планирования с учётом ошибок, рисков и проблем на предприятии.
Если говорить про промышленность, а мы ещё живём в России, то стоит проследить за историей развития отрасли. Сталин, пятилетки, промышленная революция. Конечно предприятия изменились за годы, но в основе, в фундаменте, будут именно те процессы, которые были заложены в самом начале. И да, от предприятия к предприятию они шаблонные, отличия могут вносить только специфика отрасли.
Чтобы понять модули ERP, предлагаю пройтись по цепочке процессов. Рассмотрим самое простое. У нас например больница, и есть диспетчер и сантехники. Ежемесячно диспетчер планирует работу сантехников. Обход больницы, обход операционных, например 2 раза в день. И какой-то набор запчастей, который должен быть ежемесячно. Если его не хватает, диспетчер делает запрос на склад, склад делает запрос в бухгалтерию, та всё оплачивает, потом оно поступает на склад. Что может пойти не так? Авария. Тут есть бригада и она экстренно должна реагировать и также у неё должен быть набор запчастей. А если больница большая, то ещё машина и бензин, например. Если говорить про автоматизацию, то тут процесс планирования- эксплуатации, работа склада, Интеграция с бухгалтерией и работа диспетчера с сантехниками, фиксирование задач, их приоритет и исполнение - отчётность о проведенных работах и далее новый цикл. И конечно управление сотрудниками, модуль HR, как без него.
Нюансы - это контекст предприятия, больница, операционная или обычная палата, тут и приоритет совсем другой у вызова сантехника и его задачи.
Я конечно всё очень упрощённо описала, но суть именно такая. И модули планирования, отчётности, хранилища данных и исполнения задач вы найдете на любом предприятии.
Самая знаменитая ERP система, это конечно SAP, в России есть 1С, и решения для каждой отрасли свои.
#теория #мойопыт #проITсистемы #WMS #мирвокруг #пополочкам
У меня есть рубрика про классы информационных систем, сегодня хочу её продолжить и рассказать про WMS - Warehouse Management System - Система управления складом.
Сейчас достаточно много вакансий в ИТ именно в ритейле, ядро которого это склад, конечно продажа, сайты, магазины, тоже имеют значение, но покупатель принимает решение основываясь на куче мелочей. И тут много значат качество товара и условия хранения, а это поставщики и работа склада.
🧰
Итак, что же входит в WMS - это основные процессы работы склада, где в основе лежат зоны и привязка к ним товаров. То есть весь склад разбивается на зоны, приёмка, размещение, хранение, отгрузка. 🔀 При этом хранение тоже разное, и зависит от температуры хранения. На каждом участке есть свои сотрудники 👷♂, которые отвечают за зону и процессы, которые там происходят. Передача товара осуществляется из зоны в зону, то есть от одних сотрудников к другим. Как эстафетная палочка в забеге) Принял товар передал, приехал погрузчик перенес в хранение, полежало в хранение, перешло в зону комплектации, там прибежал комплектовщик и собрал заказ, передал его и так по цепочке до отгрузки в машину, которая уже приедет к покупателю.
Привязка товаров к зонам происходит по штрихкодам, то есть сотрудник с помощью ТСД - терминала сбора данных, осуществляет привязку сканируя штрихкод товара и места, где он находится. Система учитывает условия хранения, сроки годности, поставщиков и расположение товаров на полках, чтобы просчитывать цепочки из заданий на сотрудников, которые находятся в разных зонах. При этом немаловажно понимать размещение товара, топологию склада, и оперативно её изменять под разные периоды времени работы склада. Например, перед праздниками, когда будет больше заказов, зон сборки и буферов для хранения запасов должно быть больше. Склад может иметь статическое хранение товаров, когда товар четко привязан к месту, но может быть и динамическое, тут много вольностей для перемещений.
Еще есть интересная задача по формированию оптимального маршрута перемещения сотрудника по складу, и товара в том числе, для экономии времени и уменьшения пробегов сотрудников по складу. Есть в цепочке workflow так много мелких действий, что изменяя их, можно оптимизировать работу звена, что может отразиться на производительности склада. Хочется сказать, что в положительную сторону)))
WMS системы классифицируются в зависимости от размера склада, количества товара, хранящегося на нём и бизнеса компании на:
✔️ системы начального уровня, склады небольших компаний,
✔️ коробочные системы, где основные функции зашиты и такие системы готовы к установке с выстроенными под неё процессами,
✔️ адаптируемые для больших логистических центров с распределительными центрами, где есть один центральный модуль, который поддерживает основные процессы, и модули, которые подключаются и донастраиваются по заказу,
✔️ конфигурационные, это склады с большой номенклатурой и высоким товарооборотом, тут можно сказать, что система создается с нуля, и учитываются особенности бизнеса компании.
Если вы начнете гуглить вендоров WMS систем, то увидите как их много. Википендия говорит, что на российском рынке под 50 разных. Если смотреть на рейтинги 2020, то тут можно увидеть знакомое всем название 1С :)
Остальные перечислять не буду) Про мировую практику скажу, что куда тут без SAP решения, оно есть.
На картинке данные 2019 года и ссылка на статью, для тех кому интересен подобный рынок)
https://www.solvo.ru/about/press/solvo-wms-vtoraya-samaya-populyarnaya-wms-sistema-v-rossii-po-itogam-2019/
У меня есть рубрика про классы информационных систем, сегодня хочу её продолжить и рассказать про WMS - Warehouse Management System - Система управления складом.
Сейчас достаточно много вакансий в ИТ именно в ритейле, ядро которого это склад, конечно продажа, сайты, магазины, тоже имеют значение, но покупатель принимает решение основываясь на куче мелочей. И тут много значат качество товара и условия хранения, а это поставщики и работа склада.
🧰
Итак, что же входит в WMS - это основные процессы работы склада, где в основе лежат зоны и привязка к ним товаров. То есть весь склад разбивается на зоны, приёмка, размещение, хранение, отгрузка. 🔀 При этом хранение тоже разное, и зависит от температуры хранения. На каждом участке есть свои сотрудники 👷♂, которые отвечают за зону и процессы, которые там происходят. Передача товара осуществляется из зоны в зону, то есть от одних сотрудников к другим. Как эстафетная палочка в забеге) Принял товар передал, приехал погрузчик перенес в хранение, полежало в хранение, перешло в зону комплектации, там прибежал комплектовщик и собрал заказ, передал его и так по цепочке до отгрузки в машину, которая уже приедет к покупателю.
Привязка товаров к зонам происходит по штрихкодам, то есть сотрудник с помощью ТСД - терминала сбора данных, осуществляет привязку сканируя штрихкод товара и места, где он находится. Система учитывает условия хранения, сроки годности, поставщиков и расположение товаров на полках, чтобы просчитывать цепочки из заданий на сотрудников, которые находятся в разных зонах. При этом немаловажно понимать размещение товара, топологию склада, и оперативно её изменять под разные периоды времени работы склада. Например, перед праздниками, когда будет больше заказов, зон сборки и буферов для хранения запасов должно быть больше. Склад может иметь статическое хранение товаров, когда товар четко привязан к месту, но может быть и динамическое, тут много вольностей для перемещений.
Еще есть интересная задача по формированию оптимального маршрута перемещения сотрудника по складу, и товара в том числе, для экономии времени и уменьшения пробегов сотрудников по складу. Есть в цепочке workflow так много мелких действий, что изменяя их, можно оптимизировать работу звена, что может отразиться на производительности склада. Хочется сказать, что в положительную сторону)))
WMS системы классифицируются в зависимости от размера склада, количества товара, хранящегося на нём и бизнеса компании на:
✔️ системы начального уровня, склады небольших компаний,
✔️ коробочные системы, где основные функции зашиты и такие системы готовы к установке с выстроенными под неё процессами,
✔️ адаптируемые для больших логистических центров с распределительными центрами, где есть один центральный модуль, который поддерживает основные процессы, и модули, которые подключаются и донастраиваются по заказу,
✔️ конфигурационные, это склады с большой номенклатурой и высоким товарооборотом, тут можно сказать, что система создается с нуля, и учитываются особенности бизнеса компании.
Если вы начнете гуглить вендоров WMS систем, то увидите как их много. Википендия говорит, что на российском рынке под 50 разных. Если смотреть на рейтинги 2020, то тут можно увидеть знакомое всем название 1С :)
Остальные перечислять не буду) Про мировую практику скажу, что куда тут без SAP решения, оно есть.
На картинке данные 2019 года и ссылка на статью, для тех кому интересен подобный рынок)
https://www.solvo.ru/about/press/solvo-wms-vtoraya-samaya-populyarnaya-wms-sistema-v-rossii-po-itogam-2019/
#вакансия #ритейл #БА #СА
Честно признаюсь в рекламе))) Но #реклама мне нужна! Ибо команде Утконоса нужны Аналитики!👮🕵️👲
Как бизнес, так и системные! Сейчас
интересует опыт на уровне senior, но вторым приоритетом рассматриваем и middle.
Описание вакансии кидаю по бизнес-аналитику, ибо это приоритет номер 1!
https://hh.ru/vacancy/39029078
Предлагаем заниматься разработкой системы класса #WMS с нуля, под открытие новых складов в разных городах России.
Я о таких системах рассказывала ранее #проITсистемы
Скучно точно не будет, продукт очень динамичный) Бизнес постоянно генерит идеи и сроки, всё как всегда, всё как мы любим)))
Уровень ЗП конкурентный по рынку и зависит от вашего уровня опыта и знаний. 💪
Сознательно не указываю уровень ЗП, так как мы рассматриваем кандидатов разного уровня и из разных регионов.
Если хотите подробнее узнать о нашей команде можете смело писать Максиму 👉 @BChief
Также буду благодарна рекомендациям 🙌
Честно признаюсь в рекламе))) Но #реклама мне нужна! Ибо команде Утконоса нужны Аналитики!👮🕵️👲
Как бизнес, так и системные! Сейчас
интересует опыт на уровне senior, но вторым приоритетом рассматриваем и middle.
Описание вакансии кидаю по бизнес-аналитику, ибо это приоритет номер 1!
https://hh.ru/vacancy/39029078
Предлагаем заниматься разработкой системы класса #WMS с нуля, под открытие новых складов в разных городах России.
Я о таких системах рассказывала ранее #проITсистемы
Скучно точно не будет, продукт очень динамичный) Бизнес постоянно генерит идеи и сроки, всё как всегда, всё как мы любим)))
Уровень ЗП конкурентный по рынку и зависит от вашего уровня опыта и знаний. 💪
Сознательно не указываю уровень ЗП, так как мы рассматриваем кандидатов разного уровня и из разных регионов.
Если хотите подробнее узнать о нашей команде можете смело писать Максиму 👉 @BChief
Также буду благодарна рекомендациям 🙌
hh.ru
Вакансия Бизнес-аналитик (WMS) в Москве, работа в компании Утконос. И..И.. ОНЛАЙН (вакансия в архиве)
Зарплата: не указана. Москва. Требуемый опыт: 3–6 лет. Полная занятость. Дата публикации: 08.10.2020.
#теория #мойопыт #мирвокруг #пополочкам
Давно у меня не было теории, поэтому вспомним про мою рубрику #проITсистемы где я собираю информацию про классы информационных систем. Одни классы вырастают из других и связаны между собой. Одного списка, как справочника, я не видела нигде, поэтому встречаю новый класс и фиксирую.
Какой список уже собрался:
✅ 1. CRM - https://t.me/start_in_IT/219
✅ 2. MDM - https://t.me/start_in_IT/220
✅ 3.Интеграционные решения - https://t.me/start_in_IT/221 интеграционная шина - https://t.me/start_in_IT/222 брокер - https://t.me/start_in_IT/223
✅ 4.Биллинг - https://t.me/start_in_IT/225
✅ 5.ETL - https://t.me/start_in_IT/226
✅ 6.ERP - https://t.me/start_in_IT/228
✅ 7.WMS - https://t.me/start_in_IT/242
И вот я встретила системы класса MRM, в посте ниже 👇 поговорим про них.
⚠️ А к вам вопрос, какие ещё классы систем вы встречали и которых нет у меня в списке ❓
Я думаю есть ещё что-то специфичное, что не встречалось у меня на жизненном пути))) пишите в комментариях👇
Давно у меня не было теории, поэтому вспомним про мою рубрику #проITсистемы где я собираю информацию про классы информационных систем. Одни классы вырастают из других и связаны между собой. Одного списка, как справочника, я не видела нигде, поэтому встречаю новый класс и фиксирую.
Какой список уже собрался:
✅ 1. CRM - https://t.me/start_in_IT/219
✅ 2. MDM - https://t.me/start_in_IT/220
✅ 3.Интеграционные решения - https://t.me/start_in_IT/221 интеграционная шина - https://t.me/start_in_IT/222 брокер - https://t.me/start_in_IT/223
✅ 4.Биллинг - https://t.me/start_in_IT/225
✅ 5.ETL - https://t.me/start_in_IT/226
✅ 6.ERP - https://t.me/start_in_IT/228
✅ 7.WMS - https://t.me/start_in_IT/242
И вот я встретила системы класса MRM, в посте ниже 👇 поговорим про них.
⚠️ А к вам вопрос, какие ещё классы систем вы встречали и которых нет у меня в списке ❓
Я думаю есть ещё что-то специфичное, что не встречалось у меня на жизненном пути))) пишите в комментариях👇
Telegram
Записки ИТ специалиста
#проITсистемы #мойопыт #мирвокруг #капитаночевидность #мысливслух #пополочкам #crm
CRM-системы, что это такое?
Решила я тут зафиксировать свои знания про классы или виды информационных систем.
Сподвигла меня на это реклама одного блоггера, который CRM прочитал…
CRM-системы, что это такое?
Решила я тут зафиксировать свои знания про классы или виды информационных систем.
Сподвигла меня на это реклама одного блоггера, который CRM прочитал…