Какие существуют сложности внедрения решений на базе Dyn 365 CRM?

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

Доброго времени суток. Проекты по внедрению CRM мало чем отличаются от ERP, если не ошибаюсь, у них даже есть общие шаги по SureStep. В чем-то CRM даже хуже, так как на этом проекте продажники будут продавать продажникам.


По моему опыту, ключевая проблема проектов на CRM - это неудержимый креатив экспертов. Если в мире ERP есть некий "станадрт" в части той же бухгалтерии, или склада, то в мире CRM каждый строит свой процесс по принципу кто во что горазд. В итоге получаются монструозные нерабочие решения от которых позже пытаются откреститься "заказчики" со словами что это интегратор плохо отработал, а не они изначально вырезано цензурой придумали.


Вопросы задавайте ровно те же: назовите реальные сроки, по какой методологии вы работаете, какая отчетность и контроль результатов? Ни один сейлз на это не ответит и вам покажут архитектора, который скажет как есть. Тут как и везде дилетанты работают по принципу "навались", профессионалы заставляют работать самого "заказчика". Увы, в наших широтах таки нет.


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


По архитектуре. CRM не допускает вмешательства в код платформы, поэтому, в теории, платформу всегда можно обновить до последней версии. На практике это чаще всего требует пересмотра той или иной части решения. Поэтому да, апгрейд - отдельный проект и не всегда "мини".

[newToCRM]

Небольшой вопрос на понимание:
Сегодня уточнили, что компания хостит CRM в облаке, но не Azure, а другого провадера.
Правильно ли я из этого понимаю, что значит, это, по сути, on-premise CRM, просто сидящая в облаке, а не локальном сервере, и по этой причине:
1) большого количества возможностей доступно не будет
2) как раз вопрос доплаты за расширение инфраструктуры нужно задать, тк возможность развернуть доп тест сервер или улучшить производительность будет зависеть от их соглашения с хост-провайдером облака. (MS это забесплатно дает)

Спасибо

[newToCRM]

Артем, подскажите, пожалуйста, насчет CRM архитектуры.

Я пытаюсь понять от чего зависит, когда нужно для организации разворачивать отдельную инсталляцию, а когда ее база добавляется просто к существующей CRM

Как я понимаю, в CRM(оооч упрощенно) есть:
1) основная DB - MSCRM_CONFIG - конфигурации CRM в целом и информация об организациях, развернутых в рамках этого CRM.
2) OrgName_MSCRM - DBs для конкретных организаций: т.е их данные, метаданные, и всю конфигурацию организации (включая сборки плагинов и их настройки).

(При этом, код кастомизаций
a) javascript хранится в OrgName_MSCRM)
b) плагинов - добавляется и регистрируется DLL на соответствующем сервере)

Вопрос:

Тк то, что мы рассматриваем - вертикальное решение, поэтому я не совсем понимаю, потенциально возможно, что:

• мы будем "подцеплены" к существующему CRM (то есть, у них уже есть MSCRM_CONFIG и какие-то сторонние организации, использующие это решение, т.е будут OrgName1_MSCRM..OrgNameN_MSCRM) в их облаке. Поэтому нас с нашими настройками просто добавят к этому существующему стэку как дополнительную OrgNameN_MSCRM

или же

• должна быть обязательно для нас развернута отдельная инсталляция (то есть, все эти OrgNameN в CRM -могут быть только разные подразделения одной и той же компании,что в AX реализовано через одну базу + dataareaId)

Первый вариант мне кажется абсолютно невозможным ,тк, как минимум, права доступа к CRM юзеров из разных доменов настраивать было бы проблематично, да и всю остальную инфраструктуру сложно подвязать(тот ж SP, Reporting Server), но, может, я что-то в корне недопонимаю ...

Как принимается решение, разворачивается ли отдельная инсталяция в конкретном случае ?