Добрый день. Составление обзоров продуктов дело очень нужное и полезное, хотя и неблагодарное 😊 Тем не менее, оценив прилагаемый список продуктов, я вижу существенную деталь, которая явно может повлиять на объективность сравнения систем. А деталь тем не менее, очень простая. Как мы знаем, сравнивать приемлимо системы одинакового класса. А я в этом списке вижу, навскидку, минимум три класса: MQ, они же брокеры сообщений; ESB, то есть полноценные шины данных; DMP, то есть платформы данных. Понятно что стоимость продуктов будет различаться, но часто проекты внедрения не имеют ограниченний по этому фактору, да и стоимость разных классов иногда различается несущественно. А вот функционал будет различаться и вполне ощутимо. Поэтому нужно, по моему мнению, обязательно указывать класс систем, дабы отделить мух от котлет.😊
Весьма забавный подход к, в общем-то, типовой задаче перехода на новую систему. И даже технически, интересный.
Однако, с методикой перехода большие вопросы:
1) Далеко не все справочники из УПП хорошо ложатся в УХ, маппинг достаточно неоднозначный, много трансформаций
2) Аналитичность НСИ и документов значительно выше, даже если идеальный переход с 1 января, много данных для обогащения, а если надо посередине отчётного периода?
3) Качество данных контролируется на глазок, мусор из старой системы перенесет в новую. Про управление качеством данных можно забыть
4) Реинжиниринг процессов, а CPM это совсем другой подход к бизнес-процессам
Могу и дальше продолжить список, однако я не понимаю, а зачем выбирать такую экзотику, а не делать все в экосистеме 1С?! Зачем менять стек технологий?!
Связка 1С:MDM, 1С:Шина и 1С:Аналитика с успехом делают то же самое и на более высоком методологическом уровне!🤔🤔
Проект весьма интересный, с точки зрения обменов между сайтами и распределительными системами. А вот методологические аспекты данных не затронули.
Большинство систем в контуре 1С, требования к централизации мастер-данных по SKU, каталог эталонов, и в результате выбирают собрать сложную в поддержке архитектуру с большим кастомным обменом. 🤔
Почему не рассмотрели типовые решения 1С: 1С:Шину и 1С:MDM?
То что в этом варианте трудоемкость проекта значительно снизилась и поддержку не только вы могли делать, это я понимаю. А вот то что, системно задача интерабельности и интеграции данных не решена.
Клиент получил еще одну уникальную интеграцию, без намека на унификацию и на снижение стоимости владения инфраструктурой ИТ.
До сих пор не могу понять, почему такая любовь к УРИБ? Сами же пишут что технология плохая, хают не и при этом продолжают использовать 😂
Технология родом из 90-х, понятно что устарела.
Так почему не использовать современные возможности? Автономные приложения и сервера, обмены через шину, брокеры сообщений и и.д. Мат.часть тоже нужно изучать, а не только нафталин разгребать.
Забавная статья, хорошо демонстрирующая старую притчу о трёх слепых мудрецах, которые описывали животное класса "слон обыкновенный" и сделавших три разных заключения.😊
Впрочем, и сам был таким, лет 15 назад, когда впервые для себя переводил компанию с SAP ERP R/3 на 1С 7.7. Интеграция была очень забавной. Программисты склонны ломиться напрямую, как умеют. А Дока на стороннюю систему это для чистеньких архитекторов 🤣
И потом ходят байки, про темные леса, ошибки и кривую интеграцию с 1С.
Ну а оглянуться вокруг, понять способы обмена, протоколы, специализированные системы ESB, увы это приходит с опытом.
Весьма странный способ изымать данные из 1С через костыли. Можно было использовать штатные высокоскоростные способы через платформенные сервисы интеграции.
Причем принимая во внимание наличие у крупных организаций баз на Дата Акселератора или в частном Фреше, приведенный автором способ обмена выглядит совсем архаичным в современном мире данных.
Добрый день. Составление обзоров продуктов дело очень нужное и полезное, хотя и неблагодарное 😊 Тем не менее, оценив прилагаемый список продуктов, я вижу существенную деталь, которая явно может повлиять на объективность сравнения систем. А деталь тем не менее, очень простая. Как мы знаем, сравнивать приемлимо системы одинакового класса. А я в этом списке вижу, навскидку, минимум три класса: MQ, они же брокеры сообщений; ESB, то есть полноценные шины данных; DMP, то есть платформы данных. Понятно что стоимость продуктов будет различаться, но часто проекты внедрения не имеют ограниченний по этому фактору, да и стоимость разных классов иногда различается несущественно. А вот функционал будет различаться и вполне ощутимо. Поэтому нужно, по моему мнению, обязательно указывать класс систем, дабы отделить мух от котлет.😊
Доброго времени суток!
Весьма забавный подход к, в общем-то, типовой задаче перехода на новую систему. И даже технически, интересный.
Однако, с методикой перехода большие вопросы:
1) Далеко не все справочники из УПП хорошо ложатся в УХ, маппинг достаточно неоднозначный, много трансформаций
2) Аналитичность НСИ и документов значительно выше, даже если идеальный переход с 1 января, много данных для обогащения, а если надо посередине отчётного периода?
3) Качество данных контролируется на глазок, мусор из старой системы перенесет в новую. Про управление качеством данных можно забыть
4) Реинжиниринг процессов, а CPM это совсем другой подход к бизнес-процессам
Могу и дальше продолжить список, однако я не понимаю, а зачем выбирать такую экзотику, а не делать все в экосистеме 1С?! Зачем менять стек технологий?!
Связка 1С:MDM, 1С:Шина и 1С:Аналитика с успехом делают то же самое и на более высоком методологическом уровне!🤔🤔
Доброго времени суток!
Проект весьма интересный, с точки зрения обменов между сайтами и распределительными системами. А вот методологические аспекты данных не затронули.
Большинство систем в контуре 1С, требования к централизации мастер-данных по SKU, каталог эталонов, и в результате выбирают собрать сложную в поддержке архитектуру с большим кастомным обменом. 🤔
Почему не рассмотрели типовые решения 1С: 1С:Шину и 1С:MDM?
То что в этом варианте трудоемкость проекта значительно снизилась и поддержку не только вы могли делать, это я понимаю. А вот то что, системно задача интерабельности и интеграции данных не решена.
Клиент получил еще одну уникальную интеграцию, без намека на унификацию и на снижение стоимости владения инфраструктурой ИТ.
Для этого используется 1С:Управление ландшафтом.
До сих пор не могу понять, почему такая любовь к УРИБ? Сами же пишут что технология плохая, хают не и при этом продолжают использовать 😂
Технология родом из 90-х, понятно что устарела.
Так почему не использовать современные возможности? Автономные приложения и сервера, обмены через шину, брокеры сообщений и и.д. Мат.часть тоже нужно изучать, а не только нафталин разгребать.
Забавная статья, хорошо демонстрирующая старую притчу о трёх слепых мудрецах, которые описывали животное класса "слон обыкновенный" и сделавших три разных заключения.😊
Впрочем, и сам был таким, лет 15 назад, когда впервые для себя переводил компанию с SAP ERP R/3 на 1С 7.7. Интеграция была очень забавной. Программисты склонны ломиться напрямую, как умеют. А Дока на стороннюю систему это для чистеньких архитекторов 🤣
И потом ходят байки, про темные леса, ошибки и кривую интеграцию с 1С.
Ну а оглянуться вокруг, понять способы обмена, протоколы, специализированные системы ESB, увы это приходит с опытом.
Весьма странный способ изымать данные из 1С через костыли. Можно было использовать штатные высокоскоростные способы через платформенные сервисы интеграции.
Причем принимая во внимание наличие у крупных организаций баз на Дата Акселератора или в частном Фреше, приведенный автором способ обмена выглядит совсем архаичным в современном мире данных.
Доброго времени суток. Для объективности сравнения в таблице явно не хватает Второго пилота от 1С. А так интересно почитать. Спасибо!