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

[newToCRM]

Добрый день

Есть компания, которая рассматривает возможность внедрения решения на базе Dynamics 365 CRM от Time 4Advice (cloud-based)

У нас будет скоро встреча с сейлзами и консультантами.
Мне нужно понять:

• Какие вопросы им обязательно задать на встрече на этом этапе?
• На что обратить особое внимание?
• Какие скрытые доп расходы на инфраструктуру могут понадобиться, от чего это зависит?
• Как оценить реалистичность выполнения проекта в заданные сроки?

Я "происхожу" из мира Dynamics AX, где большинство внедрений очень долгие, проблематичные, все дедлайны и бюджеты в несколько раз в итоге выше обещанных изначально сейлзами. Очень редко какой проект обходится совершенно без модификаций кода. А апгрейды на новую версию обычно отдельный проект-кошмарчик. По моему опыту это происходит из-за очень поверхностного изначального анализа бизнес-требований и желании сейлзов проекта подцепить клиента (а дальше ему уже деваться некуда), поэтому клиенту даются нереалистичные сроки и оценка . Дополнительно тут же появляются скрытые расходы на инфраструктуру (доп сервера, память (для разворачивания различных environments нужны доп сервера + сервера для Batch - processoв, потом еще и обнаруживаются доп проблемы с производительностью и снова нужно подкупать стероиды)

Хочу, чтобы мы не наступили на подобные грабли с CRM.
На данный момент у всех ожидания, что все с этим CRM проектом будет очень легко: анализ требований, data migration , настройка параментов & workflows(без кастомизаций кода) и go-live
Я читаю про архитектуру CRM и, действительно, вроде, все намного проще (на первый взгляд), поэтому вполне может быть легкое внедрение


Поделитесь,пожалуйста, опытом:

• Чем внедрение Dynamics 365 CRM отличается от внедрения AX?
• Как обычно переносится код, сколько и какие envronments бывают?
• Как обычно происходит upgrade на новую версию CRM. На сколько это травматично для бизнеса?
• Какие вопросы вы сами задаете на подобных встречах и что сразу уточняете, перед принятием решения о подписании контракта? Какие формулировки обязательно ожидаете увидеть в самом контракте?
• Как обычно строится support на проектах Dyn CRM и что должно быть обязательно прописано в контракте на support ?

Я понимаю, что много вопросов. Чем больше ясности у меня будет тем лучше. Поэтому просто поделитесь, пожалуйста, опытом по тем пунктам, что знаете.
Заранее благодарю за помощь

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

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


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


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


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


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

[newToCRM]

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

Спасибо

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

Совершенно верно: хостинг у провайдера - это обычный он-премис, со всеми вытекающими.


С точки зрения самой платформы возможности практически те же - недавно был релиз версии 9.0 на онпремис, в облаке сейчас 9.1. Но большое количество решений, сервисов и интеграций работает только в облаке, соответственно у стороннего провайдера их не будет. Тут нужно понимать насколько они для вас критичны

[newToCRM]

Спасибо. Вот такой еще вопрос:
CRM интегрирован плотно с outlook.
Дано: Dyn 365 CRM хостится в одном облаке, а весь основной бизнес компании ведется из-под другого хостинг-провайдера, где и domain controller, exchange server + все virtual desktops и доступные с них для пользователей приложения, включая outlook - в другом облаке
Я правильно понимаю, что пользователи, у кого есть доступ к CRM будут как бы просто иметь два outook клиента (один-используемый Dyn 365, а второй- обычный на их remote desktop), оба к одному exhange подсоединены. Поэтому, верно предположить, что если письма посылаются от имени пользователя из CRM, то они будут видны и в "desktop" версии в "Sent". И также верно и обратное, что получаемые будут в обоих местах отображаться.

Есть ли какие-то тонкости, что по этому поводу надо предусмотреть/иметь ввиду (помимо очевидной возможности подключиться к exchange со стороны crm)?

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

Есть нюансы. Есть интеграция с Exchange (или вообще почтой) и есть плагин для Outlook - это не одно и тоже, хотя решают схожие задачи. Для того чтобы работать с CRM не обязательно использовать ни то ни другое.


Зачем оно может быть надо?
1. Вы хотите автоматическую синхронизацию контактов, встреч и задач между CRM и Exchange
2. Вы хотите сохранять в CRM историю переписки
3. Хотите отправлять и принимать почту непосредственно в CRM (если угодно, на стороне сервера)


В зависимости от требований, вы можете выбрать то, или иное решение.


Техническая часть тоже важна. Я вижу два пути решения проблемы:
1. Создание федерации с "доменом" в котором работает CRM и тогда у ваших пользователей будет одна учетная запись и для почты и для CRM
2. Сложный путь


В любом случае удастся получить какую-то рабочую комбинацию

[newToCRM]

Огромное спасибо за развернутые ответы, Артем!
Вырисовывается канва того, что нужно прояснить, и куда еще самостоятельно копать.

[Ivanhoe]

А у вас CRM это насколько важная система для бизнеса? Доверять облаку MS не все готовы, а доверять еще более мелкому провайдеру - ну такое Что будет если они закроются? Должны быть какие-то очень веские причины идти в облачное решение такого провайдера.

Цитата:

Я "происхожу" из мира Dynamics AX, где большинство внедрений очень долгие, проблематичные, все дедлайны и бюджеты в несколько раз в итоге выше обещанных изначально сейлзами. Очень редко какой проект обходится совершенно без модификаций кода. А апгрейды на новую версию обычно отдельный проект-кошмарчик. По моему опыту это происходит из-за очень поверхностного изначального анализа бизнес-требований и желании сейлзов проекта подцепить клиента (а дальше ему уже деваться некуда), поэтому клиенту даются нереалистичные сроки и оценка . Дополнительно тут же появляются скрытые расходы на инфраструктуру (доп сервера, память (для разворачивания различных environments нужны доп сервера + сервера для Batch - processoв, потом еще и обнаруживаются доп проблемы с производительностью и снова нужно подкупать стероиды)

1. В аксапте бывают проекты разные. В том числе не очень долгие и не очень проблематичные. Тут больше не от системы зависит, а от того, что "продано" и что "куплено", а также от самих заказчиков и подрядчиков.
2. Модификации не есть абсолютное зло. Важен баланс - что вы получаете за стоимость лицензий, а что вы оплачиваете за кастом. И за какое качество кастома вы готовы платить, и какое качество может обеспечить подрядчик.
3. Обновление платформы / версии не может быть самоцелью. Вы делаете Автоматизированную систему, которая должна решать бизнес-задачи. Заложить в нее все возможные будущие бизнес-задачи не реально. Надеется на то, что в будущем обновлении платформы появится именно то, что вам нужно - ну такое.
4. Нереалистичные сроки дают странные продавцы - мнение производства не учитывается? В договоре никаких обязательств и штрафных санкций? Тогда это уже вопросы к покупателю - а что же он купил у таких продавцов?
5. Требуйте в договоре описание всех расходов, даже если какие-то еще трудно определить. Услуги на внедрение, оценку услуг по поддержке, оценку лицензий / облака / железа на старте проекта, на запуске системы, потенциально на 5 лет вперед. Явно впишите что любые дополнительные затраты за счет поставщика, пусть задумаются сразу, не стоит ли включить покупку Visual Studio (чисто пример) в закупку по договору.
6. В договоре хорошо бы хоть как-то зафиксировать состав работ/услуг по проекту. В т.ч. поймете какое тестирование предполагается. В т.ч. можно явно прописать состав сред для проекта: dev, test, build, prod или что там нужно по их методике.

В связи с облаком хорошо бы еще такие вопросы прояснить: у вас выделенная инфраструктура будет или shared с другими клиентами (мало ли). Как гарантируется производительность (если гарантируется), работоспособность, сроки восстановления в случае поломок и т.п.. Кому принадлежат права на систему и все наработки в рамках проекта. Какие работы по поддержке / администрированию облачного решения включены в стоимость.

[cuba]

Присоединяюсь к вышенаписанному)

Составьте, например, Fit & GAP и RACI.
Это даст возможность понять кол-во доработок и ресурсы участвующие в них, а отсюда и предполагаемую стоимость.

[newToCRM]

Цитата:

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

Присоединяюсь к вышенаписанному)

Составьте, например, Fit & GAP и RACI.
Это даст возможность понять кол-во доработок и ресурсы участвующие в них, а отсюда и предполагаемую стоимость.

А Вы, действительно, на проектах RACI matrix используете? На проектах мне в реальности не попадался. У вас проекты waterfall или agile обычно в CRM?

[cuba]

У меня вообще проекты АХ)
Но часто АХ внедрялся параллельно с CRM и, да, мы рисовали матрицы. По крайней мере, в Waterfall'ных точно рисовали)
В Agile\Lean etc. не рисовали, если мне память не изменеят

[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), но, может, я что-то в корне недопонимаю ...

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