OpenPIM полностью Российская разработка, можно посмотреть про это на нашем Российском сайте. Вы только в своем обзоре совсем не учли цены на внедрение (а они могут различаться в десятки раз) и вообще локальные особенность, например поддержки локальных маркетплейсов. В общем в этом обзоре маловато информации для нормального принятия решения. Brandquad в частности самы дорогой (но не значит что самый лучший)
Ну конечно, куда нам до вас... Не надо передергивать, никто не писал что хватает. Мы сами решаем на каком уровне не выдавать дальше (если надо дальше то уже надо будет посылать новый запрос). Это зависит от ситуации, но главное, что это возможно и мы сами это контролируем. Ножом можно и хлеб резать и вены... Надо самому решать как использовать инструмент.
А какая проблема с раздутием выдачи? Если выдача несколько сот килобайт то современные браузеры это скушают и нет проблем, если у вас дерево выдачи очень большое то в этом и фишка... Вы сами решаете внутренний тип будете выдавать полностью или выдадите его как другой тип (обрезанный) и не дадите ходить дальше. Надо просто понять, что нет одного правильного пути. Для каждого проекта свое... Мы например выдаем 2 уровня максимум и на втором уровне не выдаем уже сущность вложенную, а выдаем ее ID. Хочешь ее получить, делай следующий запрос...
В этом и смысл что никто не обязывает вас выдавать все дерево объектов на 5 уровней например. Вы сами определяете как вы считаете правильным. Обычно 2-3 уровня хватает (я бы даже про третий уровень подумал уже). Это в любом случае уже лучше чем прсто rest но при этом и решает все проблемы что он тут описал
Автор сам себе гемора насоздавал и жалуется... Никто не мешает не делать такую большую схему, сделай ограничение на каком то уровне и все, не давай ходить дальше и не будет проблем.
Пагинация - вообще без проблем, откуда там проблемы?
Запросы видишь ли в браузере одинаковые... Дык сделай разные. Можно тупо послать /graphql/nameOfMyRequest и сервер отлично это отработает, а nameOfMyRequest игнорирует, хотя в браузере все будет видно.
И т.д. В общем, надо уметь пользоваться инструментом. Мы используем 3 года на небольшом проекте и только рады...
я так понимаю, что ваш коментарий нужен для того чтобы показать какой вы крутой, что вы являетесь продвинутым пользователем и находитесь за пределами постсоветского пространства. То есть вы уже почти бог... Спасибо что просветили нас убогих
Ну если не нравится вам использовать клиентские библиотеки то дергайте graphql просто через fetch. В чем проблема то? Мы у себя в проекте так и делаем. graphql это же просто строка посланная через HTTP POST.
Да нет у вас никакой уникальной ситуации. Вы слишком накручиваете. И продажи начинаются не с продажников, а с того, что основатели компании продают сами, а когда уже поймут как - то можно и продажников набирать. И с разработкой - тоже самое. Сделайте первую версию (заодно поднимите свою компетенцию), а потом все равно захочется все переписать, так как и решения вы будет принимать не самые лучшие и сам продукт изменится до неузнаваемости (когда вы пойдете с ним на реальный рынок). Вы похоже просто хотите поиграть в красивый большой бизнес. (без обид)
да вы после первого mvp еще 5 раз все перепишите, не из-за технологий, а из-за того что сам продукт будет меняться. Не надо начинать бизнес с аренды офиса и найма секретарши, а надо с продаж. Так же и тут, сделайте сперва хоть что-то работающее на том, что умеете. А потом уже будет понятнее и куда продукт будет развиваться и какие технологии надо поменять и т.д.
А вам реально надо всякие там микросервисы и еще куча архитектурных слоев? Сделайте блин сперва что-то реально рабочее в одном монолите, а вот если реально это пойдет то тогда уже и понятно будет как это надо разбивать на микросервисы и т.д.
Как говорится "любую проблему можно решить введением дополнительного уровня абстракции. Кроме проблемы слишком большого количества уровней абстракции." :)
И в чем кайф после кучи лет быть наемным директором? Ваша зарплата скорее всего недалека от зарплаты любого удаленщика профессионала, который работает на запад. При этом еще куча проблем от работы на госы... Можно и в тюрьму реально загреметь, раз вы директор (примеры подобного ищите сами).
И что будет если по каким-то причинам надо будет искать новую работу? Тот же профи удаленщик найдет ее гораздо быстрее и проще, чем найти опять работу директором.
В обшем, много гемора и непонятное будущее. Нет уж, пойду дальше код пилить...
Послушайте, если вы реально хотите внедрить PIM и у вас есть вопросы как лучше решить в нем какую-то задачу, то давайте созвонимся и я все объясню. Но у меня нет времени на бесполезный спор.
Нет. Это все УЖЕ лежит на сайте. Зачем это пихать в 1с, когда можно слить из 1с цены с остатками (которые и так на сайте нужны), а с сайта слить товары с нужными свойствами/фотками?
Если вы посмотрите на саму статью то она была для тех компаний кто хранит продуктовые данные в Excel, а не на сайте. Вы конечно удивитесь, но не все могут легко управлять своим сайтом, часто бизнес платит какой-либо компании за поддержку сайта и не так просто сделать там какие-либо изменения и вообще бизнес может иметь несколько сайтов, которые принадлежат разным ООО но реально это один бизнес и т.д.
Вы не понимаете моей мысли, что есть разные варианты где хранить эти данные (таблицы, учетная система, веб сайт, PIM) и каждый из этих вариантов имеет свои плюсы и минусы и надо решать это для конкретной компании.
Тот же веб сайт он не умеет например хранить разные иерархии товаров (у него только одна она), он не умеет проверять качество данных и т.д. Это просто система которая сделана для другого. Но если ее мощности хватает для решения бизнес задач - то отлично, используйте ее и не надо вам PIM.
Вообще смешно, я уже 12 лет работают с PIM системами, запускал их (не только OpenPIM но и другие) и в России и в Европе. Уже в 2019 году мировой рынок PIM систем оценивался в 7 миллиардов долларов, а вы мне пытаетесь доказать, что это никому не надо. Это похоже на разговор слепого со зрячим, когда слепой доказывает зрячему что солнца нет потому что он его не видит. :)
Забыл написать про хранение товарной информации в интернет магазине... Это обычная практика когда у вас только этот канал продаж. И это нормально. Только интернет магазин он для продаж, а не для управления продуктовой информацией. Он умеет хранить только в одном виде. Когда этот канал только один - то не проблема.
А если каналов несколько? Интернет магазин, еще оптовый магазин (там другие цены и вообще могут быть другие данные например сроки поставок и т.д.), еще 2-3 маркетплейса и т.д.
Как этот один интернет магазин будет все это разруливать? Он умеет иметь разные иерархии для разных каналов? Он может автоматически проверять качество информации и выгружать данные в канал когда все данные проверены для этого канала (в то время как для другого канала данные могут быть еще не готовы)?
Просто каждая система создана для определенной работы, которую она умеет делать хорошо. Интернет магазин - он для продаж, если его функциональности достаточно для вас - то отлично. Но когда каналов продаж несколько то возникают проблемы.
Товарная информация - это маркетинговая информация которую видят клиенты. Все атрибуты товара, фото и видео, все зависимости и т.д.
Разные компании по разному с этим работают. Если это производитель, то из производства идут характеристики товаров и надо из этого всего сделать то, что увидит клиент. Производство может писать например хим. состав а маркетинг это выдаст в виде который нужен для клиента и т.д.
Есть ритейлеры которым надо не только пропустить через себя продуктовую информацию но и обогатить, например описания все на другом языке и надо их перевести. Или например сделать свои картинки и описания чтобы они были уникальны, или взять данные от нескольких поставщиков одного и того же товара и сделать из них что-то одной (например взять логистическую информацию от одного, другое от другого) и т.д..
Если вам не надо обогащать информацию своей, то вероятно вам PIM не нужен. Вы просто берете что вам дают поставщики и все.
Учетная система обычно не хранит маркетинговую информацию, например нафига ей знать что эта картинка для Wildberries, а другая для Озон? А для выгрузки этой информации это обязательно. Вы хотите все запихать в 1С? Это возможно технически и если вас устравивает что в ней будут работать из маркетингового отдела - то отлично. Если вы можете легко добавлять в нее атрибуты, другие иерархие и зависимости - то отлично. Технически то это возможно, но есть ли у вас в компании кто это будет делать? Насколько быстро это будет происходить после просьбы от маркетинга? Надо ответить на все это чтобы решить надо ли хранить все в 1С или завести отдельную систему, которую маркетинг сможет обслуживать с минимальным участием от ИТ отдела.
Да есть у нас все это - "товар может быть в нескольких категориях, есть связки товар-категория (модель — запчасти для модели), есть связки категория-товар (запчасти для модели в карточке модели)" и цены и остатки можно хранить (если надо для маркетинга).
И ваш пример что товар в 1С один а в PIM - другой, это все решается легко, можно иметь код 1С в системе и т.д. Это все технические мелкие проблемы которые можно всегда решить.
Интеграции - да, надо делать, но это единовременные затраты, которые потом окупаются за счет высвобождения времени работников. Если у вас уже все есть и все работает то супер и вам PIM не нужен. В статье речь была про компании которые хранят все в Excel и имеют с этим кучу проблем.
Вот у нас есть компания производитель, которая сейчас внедряет нашу систему. У них несколько брендов и на каждый бренд свой менеджер, который ведет свою таблицу. Хотя товаров не много, около 1500 но все равно полно проблем с синхронизацией этих таблиц с тем что приходит с производства. Плюс еще есть менеджеры которые отвечают за маркетплейсы, они тоже как-то договариваются с бренд менеджерами как те им дают информацию, тоже все на таблицах и тоже куча проблем. А у них еще есть партнеры (ритейлеры) кому тоже надо отдавать продуктовую информацию. И т.д.
По поводу крупности компаний, то конечно когда у тебя пара человек и несколько сотен товаров то не надо PIM. Но вот есть другая компания, ритейлер небольшой. У них один человек занимается всей товарной информацией и это явно не большая компания. Только товаров у них 11 000... Так как они пытаются продавать все что есть у поставщиков. Поэтому я бы не сказал что PIM нужен только большим компаниям. Опять же, не в размере дело, а в затратах на ведение продуктовой информации. Если даже один человек ее ведет и его зарплата например 50 тыс в месяц. То если PIM освободит 50% его времени то это экономия 25*12=300 тыс в год (это даже без учета налогов). И этот человек сможет делать больше другой работы...
Это типичная проблема технерей не понимать ограничения бизнеса.
Я верю в то, что в 1С можно все хранить и я верю что вы например как технический специалист можете сделать там все сам, быстро и бесплатно.
Проблема только в том, что в реальном бизнесе все не так. Есть например директор по маркетингу которому надо вести карточки товаров и выгружать эти данные в разные каналы, он конечно может пойти к ИТ директору и попросить настроить 1С как ему надо. Насколько это получится зависит от множества факторов, и есть и свои спецы для подержки 1С и есть ли бюджет на новые лиценции для людей из маркетинга и т.д. И вероятность того, что он получит что ему надо - очень низка и вообще не зависит от возможностей 1С.
Это нормально что сперва продуктовые данные лежат где попало, часть в Excel (если менеджерам надо отправлять это клиентам), часть в 1С (ERP), часть на сайте. С этим даже можно жить если все организовано и работает.
Только надо считать затраты на ведение такой продуктовой информации и обычно через какое-то время становится ясно что иметь одну систему только для продукции, чтобы она принадлежала маркетингу и чтобы из нее уже данные шли по другим системам - это выгодно.
Тут нет ничего особенного с технической стороны. Просто надо считать. Если затраты на поддержания такой информации уже велики, то внедрение PIM вполне может их сократить. Вас же не смущает что есть CRM системы, хотя это тоже все можно хранить в 1C. Бизнес просто делает так как выгоднее.
Я рад что у вас все такие продвинутые, но утверждать, что никто не использует Excel чтобы работать с продуктовыми данными - это сильно.
Я лично знаю 3 компании которые используют Excel и хотят заменить его на что-то более удобное.
И все еще куча компаний получает прайсы (со списками товаров) и по почте и опять же в виде Excel.
Что касается продажи на маркетплейсах, то да это имеет свои плюсы и минусы, пусть бизнес сам решает надо ему это или нет. Но если надо, то удобнее работать через PIM
Конечно можно все запихать в 1С (что собственно и в статье было), только это вам кажется что это просто, так как вы сам умеете это делать. А если посмотреть со стороны бизнеса, то им надо лицензии покупать (чтобы запустить маркетологов и менеджеров в 1C), еще неизвестно как эту увеличенную нагрузку потянет сама система и возможно надо будет что-то с этим делать. И плюс еще плати консультанту (то есть вам) на все эти изменения (и не мало).
Те же атрибуты раскидать вручную по категориям и все остальное. И при каждом изменении опять вам платить…
При этом установка специализированного решения, которое специально заточено на эту задачу будет дешевле и даже сами маркетологи смогут атрибуты и категории добавлять и т.д.
Почему по вашему существуют CRM системы? Ведь тоже можно все в 1C запихать.
как красиво, а теперь давайте посмотрим на детали (ведь дьявол как все знают в них :) ). Расскажите ка мне как ваша прекрасная 1С с модулем за 5 тыс решает такие проблемы:
1. разные категории товаров имеют разные атрибуты (ботинки например имеют другие атрибуты чем рубашка и т.д.)
2. Есть варианты товаров когда товар один (например футболка) но у нее разные цвета и размеры (то есть часть атрибутов одна и та же и только один обычно разный)
3. Разные маркетплейсы требуют разные картинки (это точно) и возможно описания (маркетинг захочет), как эти прекрасные модули с этим работают?
4. Товары надо выгружать на маркетплейс только когда у него заполнены (и запонены правильно) определенные атрибуты (разные для разных маркеплейсов)
5. Товар у вас находится в какой-то категории, только вот на каждом маркетплейсе свои категории и когда выгружаешь на него надо использовать их а не свои
и т.д.
Вот еще вчера мой клиент попросил добавить в наш PIM расчет процента заполненности атрибутов, ну то есть в процентах сколько атрибутов заполнено из всех что есть у конкретной категории товаров. Им надо видеть картину насколько плохо у них с этим и принимать меры. Это заняло у меня час работы. А как у вас?
В вашем случае (честно сказать), я бы даже «забил» на 1С и просто хранил все в Excel. Пробежаться глазами по 500 записям на экране — не сложно.
Только у большинства все сложнее чем 500 товаров с картинкой и описанием.
OpenPIM полностью Российская разработка, можно посмотреть про это на нашем Российском сайте. Вы только в своем обзоре совсем не учли цены на внедрение (а они могут различаться в десятки раз) и вообще локальные особенность, например поддержки локальных маркетплейсов. В общем в этом обзоре маловато информации для нормального принятия решения. Brandquad в частности самы дорогой (но не значит что самый лучший)
а кто вам мешал выдавать ссылки на ноды вложенные, а не снова ноды?
Ну конечно, куда нам до вас... Не надо передергивать, никто не писал что хватает. Мы сами решаем на каком уровне не выдавать дальше (если надо дальше то уже надо будет посылать новый запрос). Это зависит от ситуации, но главное, что это возможно и мы сами это контролируем. Ножом можно и хлеб резать и вены... Надо самому решать как использовать инструмент.
А какая проблема с раздутием выдачи? Если выдача несколько сот килобайт то современные браузеры это скушают и нет проблем, если у вас дерево выдачи очень большое то в этом и фишка... Вы сами решаете внутренний тип будете выдавать полностью или выдадите его как другой тип (обрезанный) и не дадите ходить дальше. Надо просто понять, что нет одного правильного пути. Для каждого проекта свое... Мы например выдаем 2 уровня максимум и на втором уровне не выдаем уже сущность вложенную, а выдаем ее ID. Хочешь ее получить, делай следующий запрос...
В этом и смысл что никто не обязывает вас выдавать все дерево объектов на 5 уровней например. Вы сами определяете как вы считаете правильным. Обычно 2-3 уровня хватает (я бы даже про третий уровень подумал уже). Это в любом случае уже лучше чем прсто rest но при этом и решает все проблемы что он тут описал
Автор сам себе гемора насоздавал и жалуется... Никто не мешает не делать такую большую схему, сделай ограничение на каком то уровне и все, не давай ходить дальше и не будет проблем.
Пагинация - вообще без проблем, откуда там проблемы?
Запросы видишь ли в браузере одинаковые... Дык сделай разные. Можно тупо послать /graphql/nameOfMyRequest и сервер отлично это отработает, а nameOfMyRequest игнорирует, хотя в браузере все будет видно.
И т.д. В общем, надо уметь пользоваться инструментом. Мы используем 3 года на небольшом проекте и только рады...
я так понимаю, что ваш коментарий нужен для того чтобы показать какой вы крутой, что вы являетесь продвинутым пользователем и находитесь за пределами постсоветского пространства. То есть вы уже почти бог... Спасибо что просветили нас убогих
Ну если не нравится вам использовать клиентские библиотеки то дергайте graphql просто через fetch. В чем проблема то? Мы у себя в проекте так и делаем. graphql это же просто строка посланная через HTTP POST.
Да нет у вас никакой уникальной ситуации. Вы слишком накручиваете. И продажи начинаются не с продажников, а с того, что основатели компании продают сами, а когда уже поймут как - то можно и продажников набирать. И с разработкой - тоже самое. Сделайте первую версию (заодно поднимите свою компетенцию), а потом все равно захочется все переписать, так как и решения вы будет принимать не самые лучшие и сам продукт изменится до неузнаваемости (когда вы пойдете с ним на реальный рынок). Вы похоже просто хотите поиграть в красивый большой бизнес. (без обид)
да вы после первого mvp еще 5 раз все перепишите, не из-за технологий, а из-за того что сам продукт будет меняться. Не надо начинать бизнес с аренды офиса и найма секретарши, а надо с продаж. Так же и тут, сделайте сперва хоть что-то работающее на том, что умеете. А потом уже будет понятнее и куда продукт будет развиваться и какие технологии надо поменять и т.д.
А вам реально надо всякие там микросервисы и еще куча архитектурных слоев? Сделайте блин сперва что-то реально рабочее в одном монолите, а вот если реально это пойдет то тогда уже и понятно будет как это надо разбивать на микросервисы и т.д.
Как говорится "любую проблему можно решить введением дополнительного уровня абстракции. Кроме проблемы слишком большого количества уровней абстракции." :)
И в чем кайф после кучи лет быть наемным директором? Ваша зарплата скорее всего недалека от зарплаты любого удаленщика профессионала, который работает на запад. При этом еще куча проблем от работы на госы... Можно и в тюрьму реально загреметь, раз вы директор (примеры подобного ищите сами).
И что будет если по каким-то причинам надо будет искать новую работу? Тот же профи удаленщик найдет ее гораздо быстрее и проще, чем найти опять работу директором.
В обшем, много гемора и непонятное будущее. Нет уж, пойду дальше код пилить...
Послушайте, если вы реально хотите внедрить PIM и у вас есть вопросы как лучше решить в нем какую-то задачу, то давайте созвонимся и я все объясню. Но у меня нет времени на бесполезный спор.
Если вы посмотрите на саму статью то она была для тех компаний кто хранит продуктовые данные в Excel, а не на сайте. Вы конечно удивитесь, но не все могут легко управлять своим сайтом, часто бизнес платит какой-либо компании за поддержку сайта и не так просто сделать там какие-либо изменения и вообще бизнес может иметь несколько сайтов, которые принадлежат разным ООО но реально это один бизнес и т.д.
Вы не понимаете моей мысли, что есть разные варианты где хранить эти данные (таблицы, учетная система, веб сайт, PIM) и каждый из этих вариантов имеет свои плюсы и минусы и надо решать это для конкретной компании.
Тот же веб сайт он не умеет например хранить разные иерархии товаров (у него только одна она), он не умеет проверять качество данных и т.д. Это просто система которая сделана для другого. Но если ее мощности хватает для решения бизнес задач - то отлично, используйте ее и не надо вам PIM.
Вообще смешно, я уже 12 лет работают с PIM системами, запускал их (не только OpenPIM но и другие) и в России и в Европе. Уже в 2019 году мировой рынок PIM систем оценивался в 7 миллиардов долларов, а вы мне пытаетесь доказать, что это никому не надо. Это похоже на разговор слепого со зрячим, когда слепой доказывает зрячему что солнца нет потому что он его не видит. :)
Забыл написать про хранение товарной информации в интернет магазине... Это обычная практика когда у вас только этот канал продаж. И это нормально. Только интернет магазин он для продаж, а не для управления продуктовой информацией. Он умеет хранить только в одном виде. Когда этот канал только один - то не проблема.
А если каналов несколько? Интернет магазин, еще оптовый магазин (там другие цены и вообще могут быть другие данные например сроки поставок и т.д.), еще 2-3 маркетплейса и т.д.
Как этот один интернет магазин будет все это разруливать? Он умеет иметь разные иерархии для разных каналов? Он может автоматически проверять качество информации и выгружать данные в канал когда все данные проверены для этого канала (в то время как для другого канала данные могут быть еще не готовы)?
Просто каждая система создана для определенной работы, которую она умеет делать хорошо. Интернет магазин - он для продаж, если его функциональности достаточно для вас - то отлично. Но когда каналов продаж несколько то возникают проблемы.
Товарная информация - это маркетинговая информация которую видят клиенты. Все атрибуты товара, фото и видео, все зависимости и т.д.
Разные компании по разному с этим работают. Если это производитель, то из производства идут характеристики товаров и надо из этого всего сделать то, что увидит клиент. Производство может писать например хим. состав а маркетинг это выдаст в виде который нужен для клиента и т.д.
Есть ритейлеры которым надо не только пропустить через себя продуктовую информацию но и обогатить, например описания все на другом языке и надо их перевести. Или например сделать свои картинки и описания чтобы они были уникальны, или взять данные от нескольких поставщиков одного и того же товара и сделать из них что-то одной (например взять логистическую информацию от одного, другое от другого) и т.д..
Если вам не надо обогащать информацию своей, то вероятно вам PIM не нужен. Вы просто берете что вам дают поставщики и все.
Учетная система обычно не хранит маркетинговую информацию, например нафига ей знать что эта картинка для Wildberries, а другая для Озон? А для выгрузки этой информации это обязательно. Вы хотите все запихать в 1С? Это возможно технически и если вас устравивает что в ней будут работать из маркетингового отдела - то отлично. Если вы можете легко добавлять в нее атрибуты, другие иерархие и зависимости - то отлично. Технически то это возможно, но есть ли у вас в компании кто это будет делать? Насколько быстро это будет происходить после просьбы от маркетинга? Надо ответить на все это чтобы решить надо ли хранить все в 1С или завести отдельную систему, которую маркетинг сможет обслуживать с минимальным участием от ИТ отдела.
Да есть у нас все это - "товар может быть в нескольких категориях, есть связки товар-категория (модель — запчасти для модели), есть связки категория-товар (запчасти для модели в карточке модели)" и цены и остатки можно хранить (если надо для маркетинга).
И ваш пример что товар в 1С один а в PIM - другой, это все решается легко, можно иметь код 1С в системе и т.д. Это все технические мелкие проблемы которые можно всегда решить.
Интеграции - да, надо делать, но это единовременные затраты, которые потом окупаются за счет высвобождения времени работников. Если у вас уже все есть и все работает то супер и вам PIM не нужен. В статье речь была про компании которые хранят все в Excel и имеют с этим кучу проблем.
Вот у нас есть компания производитель, которая сейчас внедряет нашу систему. У них несколько брендов и на каждый бренд свой менеджер, который ведет свою таблицу. Хотя товаров не много, около 1500 но все равно полно проблем с синхронизацией этих таблиц с тем что приходит с производства. Плюс еще есть менеджеры которые отвечают за маркетплейсы, они тоже как-то договариваются с бренд менеджерами как те им дают информацию, тоже все на таблицах и тоже куча проблем. А у них еще есть партнеры (ритейлеры) кому тоже надо отдавать продуктовую информацию. И т.д.
По поводу крупности компаний, то конечно когда у тебя пара человек и несколько сотен товаров то не надо PIM. Но вот есть другая компания, ритейлер небольшой. У них один человек занимается всей товарной информацией и это явно не большая компания. Только товаров у них 11 000... Так как они пытаются продавать все что есть у поставщиков. Поэтому я бы не сказал что PIM нужен только большим компаниям. Опять же, не в размере дело, а в затратах на ведение продуктовой информации. Если даже один человек ее ведет и его зарплата например 50 тыс в месяц. То если PIM освободит 50% его времени то это экономия 25*12=300 тыс в год (это даже без учета налогов). И этот человек сможет делать больше другой работы...
Это типичная проблема технерей не понимать ограничения бизнеса.
Я верю в то, что в 1С можно все хранить и я верю что вы например как технический специалист можете сделать там все сам, быстро и бесплатно.
Проблема только в том, что в реальном бизнесе все не так. Есть например директор по маркетингу которому надо вести карточки товаров и выгружать эти данные в разные каналы, он конечно может пойти к ИТ директору и попросить настроить 1С как ему надо. Насколько это получится зависит от множества факторов, и есть и свои спецы для подержки 1С и есть ли бюджет на новые лиценции для людей из маркетинга и т.д. И вероятность того, что он получит что ему надо - очень низка и вообще не зависит от возможностей 1С.
Это нормально что сперва продуктовые данные лежат где попало, часть в Excel (если менеджерам надо отправлять это клиентам), часть в 1С (ERP), часть на сайте. С этим даже можно жить если все организовано и работает.
Только надо считать затраты на ведение такой продуктовой информации и обычно через какое-то время становится ясно что иметь одну систему только для продукции, чтобы она принадлежала маркетингу и чтобы из нее уже данные шли по другим системам - это выгодно.
Тут нет ничего особенного с технической стороны. Просто надо считать. Если затраты на поддержания такой информации уже велики, то внедрение PIM вполне может их сократить. Вас же не смущает что есть CRM системы, хотя это тоже все можно хранить в 1C. Бизнес просто делает так как выгоднее.
Я рад что у вас все такие продвинутые, но утверждать, что никто не использует Excel чтобы работать с продуктовыми данными - это сильно.
Я лично знаю 3 компании которые используют Excel и хотят заменить его на что-то более удобное.
И все еще куча компаний получает прайсы (со списками товаров) и по почте и опять же в виде Excel.
Что касается продажи на маркетплейсах, то да это имеет свои плюсы и минусы, пусть бизнес сам решает надо ему это или нет. Но если надо, то удобнее работать через PIM
Те же атрибуты раскидать вручную по категориям и все остальное. И при каждом изменении опять вам платить…
При этом установка специализированного решения, которое специально заточено на эту задачу будет дешевле и даже сами маркетологи смогут атрибуты и категории добавлять и т.д.
Почему по вашему существуют CRM системы? Ведь тоже можно все в 1C запихать.
1. разные категории товаров имеют разные атрибуты (ботинки например имеют другие атрибуты чем рубашка и т.д.)
2. Есть варианты товаров когда товар один (например футболка) но у нее разные цвета и размеры (то есть часть атрибутов одна и та же и только один обычно разный)
3. Разные маркетплейсы требуют разные картинки (это точно) и возможно описания (маркетинг захочет), как эти прекрасные модули с этим работают?
4. Товары надо выгружать на маркетплейс только когда у него заполнены (и запонены правильно) определенные атрибуты (разные для разных маркеплейсов)
5. Товар у вас находится в какой-то категории, только вот на каждом маркетплейсе свои категории и когда выгружаешь на него надо использовать их а не свои
и т.д.
Вот еще вчера мой клиент попросил добавить в наш PIM расчет процента заполненности атрибутов, ну то есть в процентах сколько атрибутов заполнено из всех что есть у конкретной категории товаров. Им надо видеть картину насколько плохо у них с этим и принимать меры. Это заняло у меня час работы. А как у вас?
В вашем случае (честно сказать), я бы даже «забил» на 1С и просто хранил все в Excel. Пробежаться глазами по 500 записям на экране — не сложно.
Только у большинства все сложнее чем 500 товаров с картинкой и описанием.