Dynamics 365 partner selection
Как выбрать партнера Dynamics 365 CRM в Казахстане: вопросы до демо, CRM discovery, scope, интеграции, тендер, модель поддержки и scorecard.
Tugelbay Konabayev, Marketing Specialist · 9 июня 2026 г.
Эти блоки отвечают на практические вопросы без скрытого текста и без неподтвержденных обещаний по срокам, стоимости или результату.
Выбирайте не по красивой demo, а по способности вести discovery, описывать процессы, разделять Sales, Customer Service, Dataverse, интеграции, миграцию, ALM, поддержку и закупочный маршрут. Хороший партнер сначала уточняет scope и риски, а не обещает цену и срок на неполных вводных.
До demo спросите, какой бизнес-процесс будет показан, какие роли участвуют, какие данные нужны, какие интеграции предполагаются, как партнер ведет fit-gap, как контролирует scope, как устроены environments, ALM, testing, data migration, support and change requests после запуска.
CRM-discovery должен включать цели бизнеса, as-is и to-be процессы, роли пользователей, данные, current systems, module fit, интеграции, отчетность, security, migration, rollout countries, acceptance criteria, support model and procurement constraints. Без discovery оценка превращается в догадку.
Scope не должен начинаться со списка всех желаемых функций. Проверяйте, есть ли MVP boundary, phased roadmap, fit-gap logic, список исключений, decision owner, acceptance criteria and backlog. Если каждая идея сразу попадает в первый этап, проект почти наверняка раздут.
Заранее обсудите 1С/ERP, сайт и forms, почту, Teams, телефонию, BI, Power Platform, Dataverse, external portals, identity, data migration, master-data ownership and reporting sources. Для каждой связи нужен owner, направление обмена, error handling, support and testing approach.
Для успешного CRM-проекта важны все три слоя. Лицензии дают право использовать продукты, внедрение превращает процессы в рабочую систему, а support model удерживает качество после запуска. Ошибка - купить лицензии и считать, что CRM уже внедрена.
RFP нужен, если проект затрагивает несколько подразделений, стран, юридических лиц, модулей, интеграций, миграцию данных, формальную закупку или нескольких поставщиков. Если задача небольшая и scope понятен, сначала может хватить discovery brief и первичной оценки.
Отправьте цели, текущие системы, роли пользователей, пример pipeline или service process, список модулей, интеграции, отчетность, миграцию данных, страны rollout, языки, ограничения закупки, желаемый deadline, support expectations and критерии приемки первого этапа.
Выбирайте партнера по внедрению Dynamics 365 CRM не по красивой демонстрации и не по обещанию назвать цену без вопросов. Правильный выбор начинается с проверки того, как партнер понимает бизнес-процессы, данные, роли пользователей, Sales и Customer Service, Dataverse, интеграции, отчетность, миграцию, ALM, поддержку и закупку.
Хороший партнер не говорит “да, все сделаем”. Он уточняет, какой процесс меняется: продажи, сервис, pipeline, обращения, прогноз, история клиента, интеграция с 1С/ERP, управленческие отчеты или поддержка текущей системы. Если выбор партнера пропускает этот этап, вы рискуете сравнивать предложения, которые считают разные объемы работ.
Для Казахстана этот выбор критичен. В одном CRM-проекте часто участвуют продажи, сервис, финансы, IT, закупка, региональные филиалы, локальные системы, Microsoft 365, Power BI, Power Platform и 1С/ERP. Этот гайд не заменяет закупку, юристов и техническую проверку. Он дает практический чеклист: что спросить перед demo, что войти в CRM discovery, как не раздуть scope, какие вопросы задать об интеграциях, когда нужен RFP и какие красные флаги искать в предложении.
Главный принцип простой: партнер должен уменьшить неопределенность перед проектом, а не перенести ее в проект.
Лицензии дают право использовать систему, но не упорядочивают хаос. Если компания купит лицензии без описания ролей, данных, pipeline, lifecycle обращений, отчетности и поддержки, система останется доступом без работающих процессов. Пользователи будут обходить CRM через Excel, почту и мессенджеры.
Партнер нужен, когда проект требует не только покупки, но и проектирования рабочего контура:
Microsoft описывает партнеров Dynamics 365 как источник консультаций и поддержки при покупке, внедрении и оптимизации решений. Партнерская работа не должна ограничиваться “продать лицензию”. Она должна помочь оценить, внедрить, настроить, расширить, поддерживать и совершенствовать решение.
Но это не значит, что всякий вызов партнера - это большой проект. Иногда первый шаг - short discovery. Иногда поддержка. Иногда RFP. Иногда консультация по scope перед закупкой. Иногда отказ от лишних работ и переход на Power BI или Power Platform MVP.
Выбор партнера лучше делать через scorecard, а не по впечатлению от demo. Demo показывает красивый процесс, но не показывает, как команда работает с реальными данными, ошибками, интеграциями, запросами на изменения и пользовательским принятием.
Проверяйте шесть зон.
Партнер должен задавать вопросы о процессе, а не только о продукте. Для Sales это лиды, счета, контакты, возможности, активности, этапы, прогноз, передача предложения/заказа и пересмотр pipeline. Для Customer Service это создание обращения, управление обращениями, очереди, ожидания SLA, база знаний, история сервиса и эскалация. Для CRM/ERP mix это данные, роли, система-источник, интеграции и отчетность.
Microsoft Learn подчеркивает: scope должен определяться через процессы, роли, функции, данные и системы. Это точный критерий выбора партнера. Если он объясняет scope только модулями и лицензиями, без процессов, риск растет.
Спросите, как партнер ведет проект: как фиксируется scope, как принимаются решения, как оформляется backlog, как отделяются must-have и nice-to-have, как работает change request process, как проходят design/build/test/go-live/support stages.
Microsoft Success by Design описывает фреймворк для проектов Dynamics 365. В выборе партнера это не значит требовать красивые слова. Это значит спросить: как команда управляет решениями, успехом, рисками, тестированием и готовностью к запуску.
Предложение должно ясно определить роли: архитектор решения, функциональный консультант, технический консультант, специалист интеграции, владелец миграции, руководитель проекта, владелец тестирования, владелец обучения и владелец поддержки. В малом проекте один человек может покрывать несколько ролей, но ответственность должна быть явной.
Если предложение говорит “команда экспертов”, но не объясняет, кто решает архитектурные вопросы, кто отвечает за Dataverse, кто проверяет интеграции, кто тестирует и кто поддерживает после запуска, это красный флаг.
Dataverse важен: Dynamics 365 использует Dataverse для хранения и защиты данных. Партнер должен обсуждать не только формы и поля, но и таблицы, роли, правила бизнеса, владение данными, миграцию, дубликаты, отчетность и границы интеграции.
Если компания использует 1С, старую CRM, Excel или сайт, партнер должен спросить: какие данные - источник истины и что делать при расхождении записей.
ALM для Dynamics 365 включает процессы, окружения, управление выпусками, тестирование и поддержку. Для выбора партнера это простой вопрос: как изменения переходят из разработки в production и кто поддерживает систему после запуска.
Если партнер не обсуждает окружения, тестирование, UAT, выпуски, логирование ошибок и поддержку, он может собрать систему, но не обеспечить ее управление.
Хорошая оценка должна показывать assumptions, exclusions, dependencies, risks and next steps. Плохая оценка выглядит как фиксированная цифра без вводных. Если объем работ не описан, невозможно понять, что именно сравнивает закупка.
До demo или оценки задайте вопросы, которые показывают подход партнера.
Важна не только формальная реакция, но и качество уточнений. Если партнер честно говорит, что без process map, user roles, data list and integration assumptions нельзя дать надежную оценку, это хороший признак. Если он сразу дает “готовый пакет внедрения CRM” без контекста, нужно осторожно проверить scope.
CRM-discovery - это не встреча “покажите нам Dynamics 365”. Это рабочий этап, который переводит бизнес-задачу в понятный project scope.
Минимальный discovery должен закрывать девять блоков.
Компания должна назвать, что именно должно измениться: видимость pipeline, дисциплина активностей, качество forecast, скорость обработки обращений, прозрачность service queue, единый customer context, reporting, integration with ERP, reduction of manual work or support backlog cleanup.
Нужно описать as-is процесс: как появляется lead, как создается opportunity, кто меняет stages, как назначаются owners, как фиксируются активности, как создается case, кто отвечает за SLA, где сейчас хранятся документы, заказы, статусы и финансовый факт.
To-be процесс должен быть достаточно конкретным: какие шаги останутся, какие исчезнут, какие данные становятся обязательными, где появляются approval, notification, escalation, BI dashboard or integration event.
Партнер должен спросить о ролях: sales rep, sales manager, service agent, supervisor, finance, operations, IT admin, data owner, approver, executive viewer, external partner or regional user. Для каждой роли нужны действия, права, интерфейсы, отчеты and adoption needs.
Нужно понять, какие данные уже есть, в каком качестве, откуда они будут мигрироваться, какие duplicates есть, какие справочники спорные, какие поля обязательны and where the source of truth lives.
Discovery должен показать, нужен ли Dynamics 365 Sales, Customer Service, Finance/Supply Chain, Power Platform, Power BI, custom integration or support review. Если партнер сразу выбирает модуль без анализа процесса, это слабый подход.
Список интеграций должен включать не только “да, интегрируем с 1С”, а направления обмена, trigger, data owner, frequency, error handling, security, testing and support.
CRM без отчетности быстро превращается в базу карточек. Нужно заранее определить pipeline metrics, service metrics, forecast logic, conversion, SLA indicators, data quality metrics and Power BI needs.
Discovery должен завершиться критериями приемки: что считается готовым, кто принимает, как тестируется, как обучаются пользователи, кто поддерживает и как оформляются изменения.
Scope partner selection должен быть module-aware, но не module-obsessed. Названия продуктов важны, но они не заменяют процесс.
| Зона scope | Что проверять | Почему это важно |
|---|---|---|
| Dynamics 365 Sales | Leads, accounts, contacts, opportunities, stages, activities, forecast, sales process and reporting. | Microsoft описывает Dynamics 365 Sales как помощь продавцам строить отношения, действовать на основе информации и закрывать сделки. Но проект должен привязать это к реальному pipeline. |
| Dynamics 365 Customer Service | Cases, queues, routing, SLA, knowledge base, service lifecycle and agent/supervisor roles. | Microsoft Learn описывает Customer Service как управление сквозным жизненным циклом запросов в поддержку, от создания обращения до управления знаниями. |
| Dataverse | Tables, security roles, business rules, duplicate logic, Dynamics 365 data, Power Platform extensions. | Dataverse хранит и защищает business app data; без data model CRM быстро теряет качество. |
| ERP/1С/local systems | Source of truth, fields, direction of exchange, frequency, errors, ownership and support. | Интеграция может быть главным driver complexity, даже если CRM кажется простой. |
| Reporting and Power BI | KPIs, metric owners, refresh, security, dashboards, management cadence and data quality. | Руководство покупает не карточки CRM, а управляемость pipeline, service and customer data. |
| Support and ALM | Environments, releases, UAT, issue logging, change requests, owners and support levels. | Production CRM живет годами; без ALM и support model проект ломается после первого go-live. |
Эта таблица помогает сравнивать партнеров честнее. Один партнер может считать только Sales setup. Другой - Sales plus migration. Третий - Sales, integrations, Power BI and support. Без scope matrix закупка будет сравнивать разные корзины.
Раздутый scope появляется не потому, что система плохая или партнер слабый. Он появляется, когда все участники пытаются решить все проблемы в первом этапе. Продажи хотят pipeline, менеджер хочет прогноз, финансы хотят платежи из 1С, сервис хочет обращения, IT хочет безопасность, закупка хочет цену, пользователь хочет “как раньше, только лучше”.
Чтобы не раздуть первый этап, используйте пять правил.
Нормальный партнер не должен запрещать доработки. Но он должен объяснить цену: кастомизация усложняет тестирование, поддержку, обновления, производительность и управление изменениями. Иногда кастомизация нужна. Но если она появляется до понимания стандартных возможностей - это риск.
Интеграции часто решают судьбу CRM-проекта. На demo они выглядят как “просто передадим данные”. В реальности scope интеграции зависит от ownership, API, качества данных, безопасности, частоты, обработки ошибок, мониторинга и поддержки.
С партнером стоит обсудить:
Для каждой интеграции нужен не лозунг, а набор вопросов:
Если нужно глубже понять интеграцию Dynamics 365 и 1С, используйте отдельный guide: интеграция Dynamics 365 и 1С в Казахстане. Эта статья не дублирует архитектуру обмена, а только показывает, какие вопросы задать при выборе партнера.
Конфликты часто появляются, когда смешиваются три разных бюджета.
Лицензии — право использовать Microsoft услуги. Выбор зависит от пользователей, модулей, ролей, tenant и маршрута закупки. Этот гайд не публикует цены и не заменяет лицензионный консультант.
Внедрение — проектная работа: discovery, design, конфигурация, кастомизация где нужна, миграция, интеграции, отчеты, тестирование, обучение, готовность к запуску и документация.
Поддержка — работа после запуска: инциденты, вопросы, небольшие изменения, управление backlog, планирование выпусков, администрирование, мониторинг и улучшения.
Если партнер продает только лицензии без внедрения и поддержки, CRM не взлетит. Если только внедрение без лицензионной проверки, пользователи получат неправильный доступ. Если нет модели поддержки, первая волна запросов на изменения создаст хаос.
В коммерческом предложении эти зоны должны быть разделены. Это помогает IT, finance and procurement понять, что именно оплачивается и что не входит в первый этап.
RFP нужен не всегда. Иногда он полезен, иногда он только задерживает старт.
RFP обычно уместен, если:
Discovery может быть достаточным первым шагом, если:
Для Казахстана procurement requirements могут зависеть от типа компании, сектора, структуры собственности, внутренних политик, суммы, источника финансирования и корпоративных правил. Этот гайд не является юридической консультацией. Его практический смысл - подготовить понятные вводные, чтобы procurement owner мог выбрать правильный маршрут.
Чем лучше input, тем честнее estimate. Для первичной оценки CRM-проекта отправьте не только “нам нужна CRM”, а короткий CRM brief.
Минимальный пакет:
Если данных мало, можно начать с rough brief. Хороший партнер должен сказать, каких данных не хватает для reliable estimate.
Плохое предложение часто выглядит уверенно. Его можно проверить.
Красные флаги:
Не каждый red flag означает, что партнер плохой. Иногда это просто ранняя стадия предложения. Но если после уточнений red flags остаются, сравнивать такое предложение с более детальным нельзя.
CRM-проект в Казахстане редко ограничивается “установкой системы”. Обычно нужно учитывать филиалы, разные команды, русский и казахский контент, представительства в регионе, работу с соседними странами, локальные данные, закупочные правила и внутренние согласования.
Для rollout спросите:
Региональный rollout не должен копировать один процесс на все страны. Сначала нужно понять, какие правила общие, какие отличаются из-за локальной модели.
Используйте scorecard как рабочую таблицу для выбора. Не нужна формальная бюрократия. Оцените каждого кандидата по 1-5 и добавьте краткий комментарий.
| Критерий | Что означает хороший ответ | Что настораживает |
|---|---|---|
| Process understanding | Партнер описывает as-is/to-be процессы, роли, данные and business outcome. | Разговор сразу уходит в demo и licenses. |
| Module fit | Есть ясное разделение Sales, Customer Service, ERP, Power BI, Power Platform and support route. | Все задачи предлагается решать одним модулем. |
| Discovery quality | Есть методика сбора процессов, users, data, integrations, reporting, acceptance and risks. | Оценка дается без вводных. |
| Data and Dataverse | Партнер объясняет data model, security, ownership, migration and duplicate handling. | Data migration описана как простая загрузка. |
| Integrations | Для каждой интеграции есть direction, owner, error handling, testing and support question. | Интеграции описаны без деталей. |
| ALM and support | Есть environments, testing, deployment, change requests, issue process and post-go-live owner. | Поддержка не отделена от внедрения. |
| Proposal clarity | Понятны assumptions, exclusions, deliverables, dependencies, timeline logic and acceptance criteria. | Одна красивая сумма без состава работ. |
| Regional fit | Учитываются Казахстан, филиалы, языки, local systems, procurement and support geography. | Проект выглядит как generic CRM rollout без локального контекста. |
Финальный вопрос: какой партнер лучше всего снижает неопределенность. Не самый быстрый. Не с самой красивой demo. А тот, кто помогает понять scope, данные, риски, поддержку и следующий шаг.
Если вы только изучаете D365 как направление, начните с страницы внедрение Dynamics 365 в Казахстане. Если фокус уже понятен и это sales process, полезен маршрут Dynamics 365 Sales для отдела продаж. Если основная боль в обращениях, SLA and customer support, смотрите Dynamics 365 Customer Service для поддержки клиентов.
Если спор идет не о партнере, а о выборе между Microsoft stack, 1С and local CRM, используйте guide Dynamics 365 или 1С в Казахстане. Если вопрос уже в обмене данными, смотрите интеграция Dynamics 365 и 1С. Если Dynamics 365 уже есть, но накопились ошибки и change requests, отдельный маршрут - поддержка Dynamics 365 CRM.
Технические факты в этом гайде опираются на официальные источники Microsoft и страницы Microsoft Learn:
Этот гайд не подтверждает статус партнера Promise Group, не обещает фиксированную цену, фиксированный timeline, специальные условия Microsoft, результат закупки или гарантированный бизнес-результат. Он не является юридической, налоговой или консультацией по комплаенсу.
Нет. Microsoft directory полезен как один источник для проверки партнерской информации, но он не заменяет discovery. Нужно отдельно оценить опыт команды, методологию, подход к scope, отраслевой контекст, интеграции, поддержку и качество коммерческого предложения.
Внутренняя IT-команда может владеть tenant, данными, безопасностью и поддержкой, но D365-партнер часто нужен для process mapping, module fit, Dataverse, configuration, migration, ALM, integrations and launch readiness. Лучший формат - совместная работа, а не замена внутренней команды.
Самый частый риск - начать с demo и списка функций, не согласовав процесс, владельцев данных, роли, критерии приемки и support model. Тогда система может быть технически собрана, но пользователи не понимают, как работать и кто отвечает за изменения.
Сравнивайте не только цену. Смотрите scope assumptions, exclusions, discovery depth, team roles, module fit, integration approach, migration assumptions, testing, training, support model, change request process and acceptance criteria. Разные предложения часто считают разные объемы работ.
Dynamics 365 Sales уместен, когда главная боль - leads, accounts, contacts, opportunities, activities, pipeline, forecast and sales discipline. Если проблема не в sales process, а в service, finance, integration или reporting, партнер должен честно предложить другой маршрут.
Customer Service нужен, когда компания управляет обращениями, cases, queues, SLA, knowledge base, service history and support operations. Если сервисная команда пока работает в почте и мессенджерах, discovery должен сначала описать lifecycle обращения и роли.
Да, если проект небольшой, закупочная процедура позволяет, scope понятен, decision owner доступен и нет сложных интеграций или регуляторных ограничений. Но для крупного или спорного проекта RFP помогает зафиксировать требования и сравнить предложения честнее.
Нет. Guide помогает подготовить вопросы и вводные для CRM-проекта. Закупочные, юридические, налоговые и compliance-решения должны проверяться внутренними владельцами компании и профильными консультантами, особенно в формальных процедурах и регулируемых отраслях.
Используйте этот гайд как подготовку к первичному CRM discovery: соберите цели, процессы, роли, текущие системы, интеграции, отчеты, ограничения закупки и ожидания поддержки. После этого проще понять, нужна ли demo, RFP, Sales route, Customer Service route, integration guide или support review.
