Использование CRM в рекламном бизнесе
1661
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 - версиях типа Оракула или от мелкософта - видел только у компьютерщиков. Да и то, разработка поставщика с его же доработкой "до ума".Ну и достаточно много, правда тоже не в рекламе, видел вариаций на базе систем от 1С... но это, мне так кажется - для особых любителей геммороя.
MS Access - хорош тем, что позволяет запустить систему в работу с минимальными затратами на разработку. Особенно если число рабочих мест не более 6-8. Совершенно не требователен к знаниям разработчика. Знаю вариант, который сделан гуманитарием (достаточно развесистая БД), который программерского образования не имеет вообще - т.е. "в принципе". Далее позволяет (при грамотном начальном проетировании) вести развитие системы не отрывая людей от работы ваще. Из проблем: классика для всех продуктов от мелкософта - непроизвольные высыпания без восстановлений (архивироваться!), изумительные требования к железу, а особенно к сетевым подсистемам при даже средних нагрузках, проблемы перехода между версиями как самой ОС, так и продуктов. Переносимость - весьма и весьма условная. Тяжесть БД даже при небольших нагрузках.
MySQL + Php или чего еще. Достоинства: изумительно низкие требования к железу, максимально высокая скорость работы, бесплатность инструментария (открытый софт!). Недостатки: требуется очень грамотное начальное проектирование, учет специфик работы СУБД (встроенные механизмы - весьма условны), очень высокий начальный уровень как постановщиков задачи, проектировщиков и даже кодеров. В результате, наверное самая высокая стоимость разработки в окончательном виде. Знаю одну из таких систем, которая пишется уже лет так 5 если не больше. Работает, но все еще в "стадии доработки". В проекте учавствовало более 4 разработчиков, а на сегодня, думаю уже около 10. Размер зарплат для разработчиков такого уровня - почитайте раздел "о работе".
Наверное на сегодня, соглашусь с уже высказанным мнением: правильнее брать СРМ + СУБД (фин/техн учет) от поставщиков и, или самим, или за их счет их же силами производить адаптацию под Вашу деятельность. Типовые СРМ, которые видел сам - врядли кого-то могут "устроить" в чистом виде. Все сделано "в общем" а значит "ни для кого".
Это ИМХО. Ежели смог помочь - то пожалуйста. На абсолютную истину - не претендую.
Сейчас читают
Политические композиторы (часть 2)
324181
959
вещи, которыми не шутят
6185
32
Выбор велосипеда
50911
210
Телегин П.Н.
activist
Знаю одну из таких систем, которая пишется уже лет так 5 если не больше. Работает, но все еще в "стадии доработки". В проекте учавствовало более 4 разработчиков, а на сегодня, думаю уже около 10. Размер зарплат для разработчиков такого уровня - почитайте раздел "о работе".Чего-то узнаю в описанном "Рекламу Онлайн". Соглашусь с тем, что описанный вариант самый дорогой. И дописываться/дорабатываться он будет непрерывно пока происходит рост фирмы, так постоянно возникают новые бизнес-процессы.
Плюс собственной разработки состоит в том, что софт пишется под те бизнес-процессы которые существуют. А когда есть полуготовый продукт, то есть шанс что эти бизнес-процессы трансформируются под требования этого продукта и далеко не факт что фирма от этой трансформации выиграет.
ТОП 5
1
2
3
4