CRM vs NAV

[dalaj]

Уважаемые специалисты по CRM, вопрос к вам.
Преамбула:
Есть клиент, которому необходимо разработать и внедрить вертикальное решение для автоматизации мусорного бизнеса. Необходима вся црм функциональность плюс функциональность, специфичная для бизнеса. В частности: учёт контейнеров (движение, остатки); путевые листы, договора с различными условиями, биллинг.
У клиента в бухгалтерии уже используется NAV (также поставленный нашей компанией). Я являюсь спецом по NAV, переквалифицировавшимся в спеца по CRM. Проведена диагностика и необходимо делать предложение. Изначально планировалось делать вертикаль на xRM и интегрировать с NAV счета, оплаты, клиентов и контакты. Но в процессе диагностики стал возникать вопрос, не будет ли логичнее делать вертикаль на NAV, оставив ЦРМу ЦРМ.

Вопросы:
Видел ли кто-нибудь биллинги для ЦРМ? Есть ли у кого-нибудь практический опыт разработки полноценных отраслевых решений на платформе xRM (4.0)?

П.С. Все мануалы по ЦРМ прочитаны, экзамены сданы, вебинары по xRM просмотрены.

[a33ik]

Склады, остатки и т.п. - свойственны учётным и ERP системам. Сам видел и слышал про попытки из CRM сделать учётную систему. Очень неуспешно и Вам бы не рекомендовал. CRM это CRM и не стоит на него нагружать несвойственную ему работу. А вот интеграцию можно организовать при помощи
коннектора селении
или
Scribe

[dalaj]

Спасибо за мнение, +1 k NAV. Действительно, учёт чего-либо, это прерогатива ЕРП. Поэтому и спрашиваю. Но здесь стоит отметить, что учёт контейнеров там довольно простой (увезли-привезли), сейчас в екселе. Также - в НАВ нету договоров и биллинга(out-of-the-box), так что их всёравно придётся делать (или покупать).
Если делать всё в НАВ, возникает другая проблема - в ЦРМ в любом случае придётся дублировать сущности вертикали, т.к. основное требование клиента - зайдя в карточку црм, они хотят видеть всю информацию по нему (инциденты, счета, договора,предложения и т.д.). Также у клиента много требований, которые можно было-бы успешно решить с помощью бизнес-процессов. Типа: если у договора истекает срок годности - создать задание менеджеру, и др. Предложения они хотят делать в црм, и из них, в случае акцепта - создавать договор автоматом. МС продвигает платформу xRM именно для решения подобных задач. Также юзер НАВ, при прочих равных, существенно дороже. Как быть с этими доводами?

Про коннекторы - я его (Scribe) рассматриваю как основной вариант. Разве Celenia ещё предлагает свой? Я думал что они, заключив со scribe партнёрство, перестали свой коннектор предлагать. Кстати в НАВ 2009 R2 будет соединение out-of-the-box, поэтому не рассматриваем делать свой вариант коннектора.

[mazzy]

Цитата:

Сообщение от dalaj

Изначально планировалось делать вертикаль на xRM и интегрировать с NAV счета, оплаты, клиентов и контакты. Но в процессе диагностики стал возникать вопрос, не будет ли логичнее делать вертикаль на NAV, оставив ЦРМу ЦРМ.

не логичнее.
У MS CRM есть единственная отличная от других фишка - оффлайн режим.
Если вы оставите оплаты, счтеа, даты поставки, остатки и пр. в NAV, то автоматически лишите себя возможности работы в оффлайн режиме.

Без оффлайн режима у MS CRM и модуля CRM в NAV нет отличий.
Но вам придется держать два набора людей (программы все-таки сильно отличаются. как внутри, так и снаружи).

В общем, мое мнение: логичнее не будет.

Цитата:

Сообщение от dalaj

Но здесь стоит отметить, что учёт контейнеров там довольно простой (увезли-привезли), сейчас в екселе.

А оплаты?

Цитата:

Сообщение от dalaj

Также - в НАВ нету договоров и биллинга(out-of-the-box), так что их всёравно придётся делать (или покупать).

Есть.
Либо возьмите другой сервис-пак, либо используйте заказы как договора (как и было изначально в международной версии)

Цитата:

Сообщение от dalaj

Также у клиента много требований, которые можно было-бы успешно решить с помощью бизнес-процессов.

Не сочтите за рекламу
http://navision.mazzy.ru/lib/docflownav/
http://navision.mazzy.ru/lib/docflownav2/
http://navision.mazzy.ru/lib/docflownav3/

Цитата:

Сообщение от dalaj

Предложения они хотят делать в црм, и из них, в случае акцепта - создавать договор автоматом.

Вы сейчас говорите о одностороннем обмене.
А на самом деле обмен - двухсторонний.

Так для акцепта наверняка надо знать была ли сделана предоплата, не является ли этот клиент злостным неплательщиком, есть ли вообще "контейнеры" для данного клиента, придут ли эти "контейнеры" и т.п.

Т.е. в CRM нужно получить информацию из NAV.

Цитата:

Сообщение от dalaj

МС продвигает платформу xRM именно для решения подобных задач. Также юзер НАВ, при прочих равных, существенно дороже. Как быть с этими доводами?

Это да. Но работы по интеграции сравняют счет

Цитата:

Сообщение от dalaj

Кстати в НАВ 2009 R2 будет соединение out-of-the-box, поэтому не рассматриваем делать свой вариант коннектора.

[Артем Enot Грунин]

В действительности интеграция не избавит вас от проблем с лицензированием: все пользователи NAV чьими действиям создаются объекты в CRM должны быть лицензированы как пользователи CRM и наоборот, думаю, тоже. Рекомендую руководствоваться вопросом разумности этого решения, а не стоимостью лицензий. Было правильно сказано, что разница в цене быстро съедается стоимостью работ.
Единый интерфейс реализовать не сложно. Если данные NAV нужно только видеть, но не менять, то достаточно будет реализовать лишь веб морду к его базе. XRM значит управление произвольными отношениями, а не платформа для построения чего угодно. Делайте в NAV то что правильно делать в NAV.
Насчет оффлайн режима: не вся информация должна быть доступна оффлайн. В частности я бы запрещал вынос в оффлайн критичной финансовой информации. Не знаю как обстоят дела в Риге, а вот у одного из руководителей нашей фирмы несколько месяцев назад украли ноутбук из машины. Как бы там ни было, задачу простого зеркалирования данных между системами реализовать просто. Сложнее реализовать правильный ввод этих данных: проверки, согласования и т.д. Поэтому я бы использовал для решения этой задачи систему которая лучше для этого подходит а во вторую передавал бы readonly аналог.

[dalaj]

Сергей, спасибо за мнение.
Я понял идею, но в данном случае я исхожу из мнения, противоположного утверждению

Цитата:

Без оффлайн режима у MS CRM и модуля CRM в NAV нет отличий.

Я понимаю, что это можно долго обсуждать, перечислять плюсы и минусы, и вообще холивор завести. Я внедрял много проектов, где был NAV CRM, разработал много аддонов для него и являюсь в нашей компании главным специалистом по NAV CRM. Сейчас переквалифицировался в Dynamics CRM спеца. Внедрил несколько проектов чистого Dyn CRM. Поэтому, опираясь на опыт, я не сомневаюсь в том, что для этого клиента Dyn CRM - более подходящее решение, чем NAV CRM.
Сомнения именно в разработке специфичной функциональности. Беря во внимание факторы, описанные здесь: http://blogs.msdn.com/mscrm/archive/...amics-crm.aspx, а также, зная специфику и требования клиента, пришёл к выводу что, теоретически, ориентироваться можно и на xRM и на НАВ. Вот и спрашиваю, может кто практически сталкивался с подобными решениями.

Цитата:

Но вам придется держать два набора людей

- с этим нет проблем, эти наборы уже есть.

Цитата:

А оплаты?

- импорт оплат из НАВ

Цитата:

Либо возьмите другой сервис-пак, либо используйте заказы как договора (как и было изначально в международной версии)

Я знаю функциональность заказов, она не подходит. Требований много и большинство не существует в НАВ стандарте.

Цитата:

Не сочтите за рекламу

Читал раньше, давно. Разница в том, что в ЦРМ идёт в комплекте.

Цитата:

А на самом деле обмен - двухсторонний.
Так для акцепта наверняка надо знать была ли сделана предоплата, не является ли этот клиент злостным неплательщиком, есть ли вообще "контейнеры" для данного клиента, придут ли эти "контейнеры" и т.п.

Т.е. в CRM нужно получить информацию из NAV.

Именно это и рассматривается. Scribe это умеет. Да и мы можем сделать, если надо будет.

[dalaj]

Артём, спасибо за мнение.

Цитата:

В действительности интеграция не избавит вас от проблем с лицензированием: все пользователи NAV чьими действиям создаются объекты в CRM должны быть лицензированы как пользователи CRM и наоборот, думаю, тоже.

Действительно, с лицензированием мутный вопрос. Теоретически, так и есть, практически, когда есть коннектор между системами, который обновляет данные в обе стороны, никто не покупает столько лицензий. Сервер приложений платится за 1 штуку, C-FRONT, также нужен 1 юзер. Для ЦРМ - нужен 1 full device CAL, чтобы подключатся к сервисам и обновлять/читать.

Цитата:

Насчет оффлайн режима:

В данном проекте оффлайн возможность - как бонус, а не требование, соответсвенно есть она или нет - не критично.
В остальном, мнение понятно, сказать нечего.