Использование CRM в рекламном бизнесе
1676
7
Dmitriy_B
veteran
Подскажите, использует ли кто нибудь CRM в работе, связанной с рекламой? Если да, то поделитесь информацией, какие системы и каково Ваше мнение?
В частности интересно, использует ли кто нибудь систему PrintEffect? Есть ли примеры внедрения данной программы в Новосибирске?
В частности интересно, использует ли кто нибудь систему PrintEffect? Есть ли примеры внедрения данной программы в Новосибирске?
Гы. Проще сказать кто еще НЕ использует...
В основном видел доморощенные варианты.

В основном видел доморощенные варианты.
Доморощенные - это, в смысле, дописки своими силами или мелких программеров?
Мы (ДубльГИС) используем, в 2003-2006 годах был Sales Expert с конфигуратором, сейчас собственная CRM. Насколько помню, Petra также использует собственную CRM (по крайней мере, занимались этим вопросом точно). Некоторые мнения можно почитать здесь =))
По PrintEffect - это, я так понимаю, для полиграфистов? Может, стоит обратиться к разработчику и спросить, у кого можно получить отзыв о внедрении? Еще, думаю, в крупных типографиях (Харменс, Вояж и т.п.) наверняка должны быть CRM, но какие именно - это вопрос.
По PrintEffect - это, я так понимаю, для полиграфистов? Может, стоит обратиться к разработчику и спросить, у кого можно получить отзыв о внедрении? Еще, думаю, в крупных типографиях (Харменс, Вояж и т.п.) наверняка должны быть CRM, но какие именно - это вопрос.
Ну так вот и интересно, кто какие. А то программ великое множество, посмотрел тоже немало, но видимо все таки придется писать тоже под себя.
Петра делала на основе КлиентКоммуникатора насколько я знаю. Его тоже рассматривали. Просто на первое время хотели ограничится стандартной программой.
Петра делала на основе КлиентКоммуникатора насколько я знаю. Его тоже рассматривали. Просто на первое время хотели ограничится стандартной программой.
чаще всего сейчас покупают решения поставщиков, а потом дорабатывают. и на мой взгляд правильно делают, потому что поддержка самописных программ потом влетает в коопеечку. вобщем доработанные гготовые решения в итоге выходят дешевле
Видел несколько вариантов на MS Access (у самого такое же "чудо"), "спайка" MySQL + Perl/PhP (здесь сам - уже не специалист), есть до сих пор работающие варианты даже на Paradox 3.5 - 4.1 еще с 199(2-5)гг.!
Как максимальную экзотику видел полуавтоматизированную БД на базе макросов на MS Excel 5.0 - знаю что еще работает... в том числе и в разделе учета финансовых средств... InterBase + Pascal/Delphi активно используются... правда видел только у газетчиков... Вот чего-то на серъезных SQL - версиях типа Оракула или от мелкософта - видел только у компьютерщиков. Да и то, разработка поставщика с его же доработкой "до ума".
Ну и достаточно много, правда тоже не в рекламе, видел вариаций на базе систем от 1С... но это, мне так кажется - для особых любителей геммороя.
MS Access - хорош тем, что позволяет запустить систему в работу с минимальными затратами на разработку. Особенно если число рабочих мест не более 6-8. Совершенно не требователен к знаниям разработчика. Знаю вариант, который сделан гуманитарием (достаточно развесистая БД), который программерского образования не имеет вообще - т.е. "в принципе". Далее позволяет (при грамотном начальном проетировании) вести развитие системы не отрывая людей от работы ваще. Из проблем: классика для всех продуктов от мелкософта - непроизвольные высыпания без восстановлений (архивироваться!), изумительные требования к железу, а особенно к сетевым подсистемам при даже средних нагрузках, проблемы перехода между версиями как самой ОС, так и продуктов. Переносимость - весьма и весьма условная. Тяжесть БД даже при небольших нагрузках.
MySQL + Php или чего еще. Достоинства: изумительно низкие требования к железу, максимально высокая скорость работы, бесплатность инструментария (открытый софт!). Недостатки: требуется очень грамотное начальное проектирование, учет специфик работы СУБД (встроенные механизмы - весьма условны), очень высокий начальный уровень как постановщиков задачи, проектировщиков и даже кодеров. В результате, наверное самая высокая стоимость разработки в окончательном виде. Знаю одну из таких систем, которая пишется уже лет так 5 если не больше. Работает, но все еще в "стадии доработки". В проекте учавствовало более 4 разработчиков, а на сегодня, думаю уже около 10. Размер зарплат для разработчиков такого уровня - почитайте раздел "о работе".
Наверное на сегодня, соглашусь с уже высказанным мнением: правильнее брать СРМ + СУБД (фин/техн учет) от поставщиков и, или самим, или за их счет их же силами производить адаптацию под Вашу деятельность. Типовые СРМ, которые видел сам - врядли кого-то могут "устроить" в чистом виде. Все сделано "в общем" а значит "ни для кого".
Это ИМХО. Ежели смог помочь - то пожалуйста. На абсолютную истину - не претендую.
Как максимальную экзотику видел полуавтоматизированную БД на базе макросов на MS Excel 5.0 - знаю что еще работает... в том числе и в разделе учета финансовых средств... InterBase + Pascal/Delphi активно используются... правда видел только у газетчиков... Вот чего-то на серъезных SQL - версиях типа Оракула или от мелкософта - видел только у компьютерщиков. Да и то, разработка поставщика с его же доработкой "до ума".


MS Access - хорош тем, что позволяет запустить систему в работу с минимальными затратами на разработку. Особенно если число рабочих мест не более 6-8. Совершенно не требователен к знаниям разработчика. Знаю вариант, который сделан гуманитарием (достаточно развесистая БД), который программерского образования не имеет вообще - т.е. "в принципе". Далее позволяет (при грамотном начальном проетировании) вести развитие системы не отрывая людей от работы ваще. Из проблем: классика для всех продуктов от мелкософта - непроизвольные высыпания без восстановлений (архивироваться!), изумительные требования к железу, а особенно к сетевым подсистемам при даже средних нагрузках, проблемы перехода между версиями как самой ОС, так и продуктов. Переносимость - весьма и весьма условная. Тяжесть БД даже при небольших нагрузках.
MySQL + Php или чего еще. Достоинства: изумительно низкие требования к железу, максимально высокая скорость работы, бесплатность инструментария (открытый софт!). Недостатки: требуется очень грамотное начальное проектирование, учет специфик работы СУБД (встроенные механизмы - весьма условны), очень высокий начальный уровень как постановщиков задачи, проектировщиков и даже кодеров. В результате, наверное самая высокая стоимость разработки в окончательном виде. Знаю одну из таких систем, которая пишется уже лет так 5 если не больше. Работает, но все еще в "стадии доработки". В проекте учавствовало более 4 разработчиков, а на сегодня, думаю уже около 10. Размер зарплат для разработчиков такого уровня - почитайте раздел "о работе".

Наверное на сегодня, соглашусь с уже высказанным мнением: правильнее брать СРМ + СУБД (фин/техн учет) от поставщиков и, или самим, или за их счет их же силами производить адаптацию под Вашу деятельность. Типовые СРМ, которые видел сам - врядли кого-то могут "устроить" в чистом виде. Все сделано "в общем" а значит "ни для кого".

Это ИМХО. Ежели смог помочь - то пожалуйста. На абсолютную истину - не претендую.

Сейчас читают
Аренда квартир (часть 24)
146888
769
Ремонт телефонов - 2 (часть 2)
466563
850
Дневной дозор.
185912
1000
Телегин П.Н.
activist
Знаю одну из таких систем, которая пишется уже лет так 5 если не больше. Работает, но все еще в "стадии доработки". В проекте учавствовало более 4 разработчиков, а на сегодня, думаю уже около 10. Размер зарплат для разработчиков такого уровня - почитайте раздел "о работе".Чего-то узнаю в описанном "Рекламу Онлайн".![]()

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

ТОП 5
2